[jira] [Resolved] (ACCUMULO-3447) No way to programmatically get table's TimeType
[ https://issues.apache.org/jira/browse/ACCUMULO-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-3447. -- Resolution: Done Closing ticket as it is replaced by Accumulo GitHub issue #2910 (Add ability to retrieve TimeType for a table). > No way to programmatically get table's TimeType > --- > > Key: ACCUMULO-3447 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3447 > Project: Accumulo > Issue Type: Improvement > Components: client >Reporter: John Vines >Priority: Major > > Looking through the APIs to try to determine a table's time type and it seems > like there's no mechanism for it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ACCUMULO-4635) Add documentation about auditing to user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4635. -- Resolution: Duplicate [https://github.com/apache/accumulo/issues/1136] > Add documentation about auditing to user manual > --- > > Key: ACCUMULO-4635 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4635 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Sean Busbey >Priority: Critical > > Right now the user manual makes no mention of our auditing capabilities. We > should cover operational concerns: > * Where does the audit log go? Can I change it? > * What Accumulo actions get audited? Can I change it? > * What information is included in the audit log entries? Can I change it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4355) Provide more granular control for bulk import operations
[
https://issues.apache.org/jira/browse/ACCUMULO-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4355.
--
Resolution: Resolved
The remaining sub-tasks of this ticket applied to the legacy bulk import, which
has been superseded by the newer bulk import API.
> Provide more granular control for bulk import operations
>
>
> Key: ACCUMULO-4355
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4355
> Project: Accumulo
> Issue Type: Wish
> Components: master, tserver
>Reporter: Shawn Walker
>Assignee: Shawn Walker
>Priority: Major
> Fix For: 2.0.0
>
>
> Accumulo currently provides mechanisms to initiate bulk imports and to list
> bulk imports in progress. Scheduling of bulk import requests is not entirely
> deterministic, and most of the execution of a bulk-import request is done in
> a non-preemptable manner. As such, any bulk import which takes very long to
> complete can block bulk imports with higher operational priority for
> significant periods.
> To better support bulk-import-heavy applications, it would be nice if
> Accumulo would offer additional mechanisms for controlling the scheduling and
> execution of bulk imports, such as the abilities to:
> * Pause/resume bulk import in progress.
> * Prioritize/reprioritize bulk import requests.
> * Cancel bulk import in progress. If possible, cancelling a partially
> completed bulk import request should result in a rollback of changes. That
> is, a bulk import should either succeed or make no changes.
> Additionally, for multitenant situations, it would be nice if Accumulo would:
> * Provide multiple queues for bulk import requests. Each queue would have
> its requests worked serially in priority order. Requests in separate queues
> should be worked in parallel, or have time distributed among the queues in
> some manner as to make work appear roughly parallel.
>
> Implementation-wise, I'm thinking of rewriting much of the current
> bulk-loading logic. While the current logic depends upon multiple threads
> executing (potentially long-duration) blocking RPC calls, I'd like to move to
> a more event-driven/message-passing model backed by a persistent state
> machine.
> Current ideas I'm playing around with (very tentative)
> * Creating a new table {{accumulo.bulk_load_queues}} to keep track of bulk
> load progress.
> * Distributing bulk load orchestration via a mechanism similar to tablet
> assignment instead of the current blocking RPC calls (LoadFiles.java:156).
> * Implementing something akin to a two-phase commit to achieve rollback
> behavior on failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4794) Pause/resume in-progress bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4794. -- Resolution: Won't Fix This applied to the legacy bulk import, which has been superseded by the newer bulk import API. > Pause/resume in-progress bulk imports > - > > Key: ACCUMULO-4794 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4794 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > > Accumulo currently provides mechanisms to initiate bulk imports and to list > bulk imports in progress. Scheduling of bulk import requests is not entirely > deterministic, and most of the execution of a bulk-import request is done in > a non-preemptable manner. As such, any bulk import which takes very long to > complete can block bulk imports with higher operational priority for > significant periods. > To better support bulk-import-heavy applications, it would be nice if > Accumulo would offer additional mechanisms for controlling the scheduling and > execution of bulk imports > The ability to pause in-progress bulk imports and then rresume them is > desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4793) Prioritize/Reprioritize bulk import requests
[ https://issues.apache.org/jira/browse/ACCUMULO-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4793. -- Resolution: Won't Fix This applied to the legacy bulk import, which has been superseded by the newer bulk import API. > Prioritize/Reprioritize bulk import requests > > > Key: ACCUMULO-4793 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4793 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > > Accumulo currently provides mechanisms to initiate bulk imports and to list > bulk imports in progress. Scheduling of bulk import requests is not entirely > deterministic, and most of the execution of a bulk-import request is done in > a non-preemptable manner. As such, any bulk import which takes very long to > complete can block bulk imports with higher operational priority for > significant periods. > To better support bulk-import-heavy applications, it would be nice if > Accumulo would offer additional mechanisms for controlling the scheduling and > execution of bulk imports. > One such capability would be the ability to prioritize and re-prioritize bulk > import requests. Recent discussions with customers reveal this to be the > highest priority on their feature request wish list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4796) Provide multiple queues for bulk import requests
[ https://issues.apache.org/jira/browse/ACCUMULO-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4796. -- Resolution: Won't Fix This applied to the legacy bulk import, which has been superseded by the newer bulk import API. > Provide multiple queues for bulk import requests > > > Key: ACCUMULO-4796 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4796 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > > On multi tenant situations, it would be nice if Accumulo would provide > multiple queues for bulk import requests. Each queue would have its requests > worked serially in priority order. Requests in separate queues should be > worked in parallel, or have time distributed among the queues in some manner > as to make work appear roughly parallel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4007) Shell "grep" command takes "-pn" option, but it doesn't work
[
https://issues.apache.org/jira/browse/ACCUMULO-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4007.
--
Resolution: Duplicate
See https://github.com/apache/accumulo/issues/1129
> Shell "grep" command takes "-pn" option, but it doesn't work
>
>
> Key: ACCUMULO-4007
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4007
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.5.3, 1.5.4, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.7.0
>Reporter: Eric Newton
>Priority: Major
> Labels: newbie
>
> I created an iterator to count key values, and it works for scan, but not
> when using the grep or egrep command.
> {noformat}
> shell> setshelliter -class MyCountingIterator -p 100 -pn count
> shell> scan -pn count
> row1 cf:cq [] 12345
> shell> grep row1 -pn count
> row1 cf:aa [] value
> row1 cf:ab [] value
> row1 cf:cq [] value
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4807. -- Resolution: Duplicate > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619039#comment-16619039 ] Mark Owens edited comment on ACCUMULO-4807 at 9/18/18 12:21 PM: This ticket will be closed and replaced by GitHub issue [#650|https://github.com/apache/accumulo/issues/650] was (Author: jmark99): This ticket will be closed and replaced by GitHub issue [#650|[https://github.com/apache/accumulo/issues/650]] > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619039#comment-16619039 ] Mark Owens commented on ACCUMULO-4807: -- This ticket will be closed and replaced by GitHub issue [#650|[https://github.com/apache/accumulo/issues/650]] > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4807: Assignee: (was: Mark Owens) > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619023#comment-16619023 ] Mark Owens commented on ACCUMULO-4807: -- [~etcoleman], in that case I will remove myself as assignee as I have not had the opportunity to get to it yet anyway. I will also close it out here and add a corresponding ticket in Github issues. > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617730#comment-16617730 ] Mark Owens commented on ACCUMULO-4807: -- [~etcoleman], given the monitoring work you are working on, is this ticket still relevant or will it be handled by your work? > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561980#comment-16561980
]
Mark Owens edited comment on ACCUMULO-4808 at 7/30/18 2:33 PM:
---
Duplicated by Github Issue [%573|https://github.com/apache/accumulo/issues/573]
was (Author: jmark99):
See Github Issue [%573|https://github.com/apache/accumulo/issues/573]
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4808.
--
Resolution: Duplicate
See Github Issue [%573|https://github.com/apache/accumulo/issues/573]
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561977#comment-16561977
]
Mark Owens commented on ACCUMULO-4808:
--
This issue is not represented by the GitHub issue
[#573|https://github.com/apache/accumulo/issues/573]
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4158:
Assignee: (was: Mark Owens)
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Priority: Minor
> Attachments: ep-main.summary, ep-tests.summary
>
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Trace 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Fate 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Start 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Core 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
> accumulo-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 595 source files to
> /Users/mjwall/NetBeansProjects/accumulo-mjwall/core/target/classes
> /Users/mjwall/NetBeansProjects/accumulo-mjwall/core/src/main/java/org/apache/accumulo/core/data/Value.java:80:
> warning:
[jira] [Commented] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468771#comment-16468771
]
Mark Owens commented on ACCUMULO-4158:
--
Un-assigning myself from ticket since I haven't had opportunity to spend much
time working on it. I have made use of errorprone to enforce missing override
annotations on ACCUMULO-2537 and generally like the tool. But I'm not sure it
is able to handle the range of issues that Findbugs currently deals with at
this time. I have not had time to make that detailed comparison.
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Assignee: Mark Owens
>Priority: Minor
> Attachments: ep-main.summary, ep-tests.summary
>
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Trace 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Fate 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Start 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Core 1.6.6-SNAPSHOT
> [INFO]
>
[jira] [Resolved] (ACCUMULO-2537) Add @Override Annotations
[ https://issues.apache.org/jira/browse/ACCUMULO-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-2537. -- Resolution: Duplicate Duplicate of [https://github.com/apache/accumulo/pull/476.] > Add @Override Annotations > - > > Key: ACCUMULO-2537 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2537 > Project: Accumulo > Issue Type: Task >Reporter: Mike Drob >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We should add @Override annotations to methods in our code. This can be > detected and fixed automatically using eclipse. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-2537) Add @Override Annotations
[ https://issues.apache.org/jira/browse/ACCUMULO-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-2537: Assignee: Mark Owens > Add @Override Annotations > - > > Key: ACCUMULO-2537 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2537 > Project: Accumulo > Issue Type: Task >Reporter: Mike Drob >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We should add @Override annotations to methods in our code. This can be > detected and fixed automatically using eclipse. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ACCUMULO-4697) tablet server could kick off too many idle compactions
[ https://issues.apache.org/jira/browse/ACCUMULO-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens closed ACCUMULO-4697. Duplicated by Github issue [#420|https://github.com/apache/accumulo/pull/420] > tablet server could kick off too many idle compactions > -- > > Key: ACCUMULO-4697 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4697 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Adam Fuchs >Assignee: Mark Owens >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Tablet.initiateMajorCompaction() always returns false, but we check the > return value when accounting for the number of idle major compactions started > in TabletServer.MajorCompactor.run() and continue to kick off idle > compactions on every tablet. > DefaultCompactionStrategy doesn't do anything special for idle compactions, > so this will only be an issue with a custom CompactionStrategy. > My guess would be the best thing to do would be to get rid of idle > compactions and get rid of the return value on initiateMajorCompaction(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4697) tablet server could kick off too many idle compactions
[ https://issues.apache.org/jira/browse/ACCUMULO-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4697. -- Resolution: Duplicate This ticket is now represented by Github Issue [#420|https://github.com/apache/accumulo/pull/420] > tablet server could kick off too many idle compactions > -- > > Key: ACCUMULO-4697 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4697 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Adam Fuchs >Assignee: Mark Owens >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Tablet.initiateMajorCompaction() always returns false, but we check the > return value when accounting for the number of idle major compactions started > in TabletServer.MajorCompactor.run() and continue to kick off idle > compactions on every tablet. > DefaultCompactionStrategy doesn't do anything special for idle compactions, > so this will only be an issue with a custom CompactionStrategy. > My guess would be the best thing to do would be to get rid of idle > compactions and get rid of the return value on initiateMajorCompaction(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4791) setshelliter command has incorrect usage statement
[ https://issues.apache.org/jira/browse/ACCUMULO-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4791. -- Resolution: Resolved > setshelliter command has incorrect usage statement > -- > > Key: ACCUMULO-4791 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4791 > Project: Accumulo > Issue Type: Bug > Components: shell >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Labels: pull-request-available > Fix For: 1.9.0, 2.0.0 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > When using the Accumulo shell, the setshelliter command should not require a > table name and the usage indicates that a table name is optional, as > expected. But the command will fail unless an existing table name is > supplied. Most likely due to the fact that setshelliter extends setiter, > which does require a valid table name. > The setshelliter command should be updated to work as the current usage > indicates, i.e., no table name should be required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4791) setshelliter command has incorrect usage statement
[ https://issues.apache.org/jira/browse/ACCUMULO-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405365#comment-16405365 ] Mark Owens commented on ACCUMULO-4791: -- yes, i've started looking at it. > setshelliter command has incorrect usage statement > -- > > Key: ACCUMULO-4791 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4791 > Project: Accumulo > Issue Type: Bug > Components: shell >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Fix For: 1.9.0, 2.0.0 > > > When using the Accumulo shell, the setshelliter command should not require a > table name and the usage indicates that a table name is optional, as > expected. But the command will fail unless an existing table name is > supplied. Most likely due to the fact that setshelliter extends setiter, > which does require a valid table name. > The setshelliter command should be updated to work as the current usage > indicates, i.e., no table name should be required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4791) setshelliter command has incorrect usage statement
[ https://issues.apache.org/jira/browse/ACCUMULO-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4791: Assignee: Mark Owens > setshelliter command has incorrect usage statement > -- > > Key: ACCUMULO-4791 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4791 > Project: Accumulo > Issue Type: Bug > Components: shell >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Fix For: 1.9.0, 2.0.0 > > > When using the Accumulo shell, the setshelliter command should not require a > table name and the usage indicates that a table name is optional, as > expected. But the command will fail unless an existing table name is > supplied. Most likely due to the fact that setshelliter extends setiter, > which does require a valid table name. > The setshelliter command should be updated to work as the current usage > indicates, i.e., no table name should be required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-3389) Iterator Names can't contain dots
[ https://issues.apache.org/jira/browse/ACCUMULO-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens updated ACCUMULO-3389: - Fix Version/s: (was: 1.7.4) > Iterator Names can't contain dots > - > > Key: ACCUMULO-3389 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3389 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: John Vines >Assignee: Mark Owens >Priority: Major > Fix For: 1.9.0, 2.0.0 > > > Attempting to attach an interator who's name includes dots results in > messages on the remote end from IteratorUtil - "Unrecognizable option: > ITERNAME". No errors no warnings, when they are attempted to be attached. > They get added to the config without issue. > But when you do something like listiter, they don't show up and then warnings > appear in the logs/on the monitor. > We should either: > A. allow iterators with dots in the name > B. doc that this isn't allowed and check server side when they are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-3389) Iterator Names can't contain dots
[ https://issues.apache.org/jira/browse/ACCUMULO-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390382#comment-16390382 ] Mark Owens commented on ACCUMULO-3389: -- That's the option I selected. Question, this has 1.7.4 listed as a fix version. Are we still making updates to 1.7.4 at this time or should it be worked on the 1.8 line? > Iterator Names can't contain dots > - > > Key: ACCUMULO-3389 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3389 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: John Vines >Assignee: Mark Owens >Priority: Major > Fix For: 1.7.4, 1.9.0, 2.0.0 > > > Attempting to attach an interator who's name includes dots results in > messages on the remote end from IteratorUtil - "Unrecognizable option: > ITERNAME". No errors no warnings, when they are attempted to be attached. > They get added to the config without issue. > But when you do something like listiter, they don't show up and then warnings > appear in the logs/on the monitor. > We should either: > A. allow iterators with dots in the name > B. doc that this isn't allowed and check server side when they are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-3389) Iterator Names can't contain dots
[ https://issues.apache.org/jira/browse/ACCUMULO-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-3389: Assignee: Mark Owens > Iterator Names can't contain dots > - > > Key: ACCUMULO-3389 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3389 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: John Vines >Assignee: Mark Owens >Priority: Major > Fix For: 1.7.4, 1.9.0, 2.0.0 > > > Attempting to attach an interator who's name includes dots results in > messages on the remote end from IteratorUtil - "Unrecognizable option: > ITERNAME". No errors no warnings, when they are attempted to be attached. > They get added to the config without issue. > But when you do something like listiter, they don't show up and then warnings > appear in the logs/on the monitor. > We should either: > A. allow iterators with dots in the name > B. doc that this isn't allowed and check server side when they are set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367311#comment-16367311
]
Mark Owens commented on ACCUMULO-4808:
--
[~kturner], the second option may be the way to go. After talking with
[~etcoleman] yesterday, one of the big issues is the need to have the newly
split tablets nicely distributed across the cluster. Currently that is achieved
by adding the splits, taking the table offline and bringing it back online to
achieve that result.
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365891#comment-16365891 ] Mark Owens commented on ACCUMULO-4806: -- [~etcoleman] There is some discussion on modifying the way bulk imports work in general. The proposed change is described in ticket [ACCUMULO-4813|https://issues.apache.org/jira/browse/ACCUMULO-4813]. Can you read over that ticket and provide some thoughts from your perspective? This would provide the users control in how bulk imports are done. It is thought that if this was pursued it would negate the need for some of the other recently created bulk import sub-tasks. If the bulk import process time could be drop to under a minute, for example, the need for pause/resume would not really be needed, etc. > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4697) tablet server could kick off too many idle compactions
[ https://issues.apache.org/jira/browse/ACCUMULO-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4697: Assignee: Mark Owens > tablet server could kick off too many idle compactions > -- > > Key: ACCUMULO-4697 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4697 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Adam Fuchs >Assignee: Mark Owens >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Tablet.initiateMajorCompaction() always returns false, but we check the > return value when accounting for the number of idle major compactions started > in TabletServer.MajorCompactor.run() and continue to kick off idle > compactions on every tablet. > DefaultCompactionStrategy doesn't do anything special for idle compactions, > so this will only be an issue with a custom CompactionStrategy. > My guess would be the best thing to do would be to get rid of idle > compactions and get rid of the return value on initiateMajorCompaction(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4808:
-
Issue Type: New Feature (was: Sub-task)
Parent: (was: ACCUMULO-4355)
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4807) Provide means to determine if bulk import was successful
[ https://issues.apache.org/jira/browse/ACCUMULO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4807: Assignee: Mark Owens > Provide means to determine if bulk import was successful > > > Key: ACCUMULO-4807 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > One thing customers would like to be able to do is know whether a bulk import > that was launched was successful. If a client launches a bulk import and then > dies (a rare case, but it happens), there's no way to know if that bulk > import completed or is still in progress. Possibly, if bulk import returned a > transaction ID, they'd be able to inquire whether that transaction has > completed. Not sure if think that's currently possible via the java client, > but operators do consistently monitor FATEs via the shell. It'd be nice to do > that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4808) Add splits to table at table creation.
[
https://issues.apache.org/jira/browse/ACCUMULO-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4808:
Assignee: Mark Owens
> Add splits to table at table creation.
> --
>
> Key: ACCUMULO-4808
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
> Project: Accumulo
> Issue Type: Sub-task
> Components: master, tserver
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Major
> Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now
> allow iterator and locality groups to be created at table creation. Do the
> same with splits. Comment below from
> [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
> the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or
> when table is offline. When the other API changes were made by Mark, I
> wondered if this task could also could be done at that time - but I believe
> that it was more complicated.
> The delay is that when a table is created and then the splits added and then
> taken offline there is a period proportional to the number of splits as they
> are off-loaded from the tserver where they originally got assigned. (The
> re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline
> so that the delay for shedding the tablets could be avoided, then the need to
> perform the actual import offline would not be as necessary.
>
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ACCUMULO-4808) Add splits to table at table creation.
Mark Owens created ACCUMULO-4808:
Summary: Add splits to table at table creation.
Key: ACCUMULO-4808
URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
Project: Accumulo
Issue Type: Sub-task
Components: master, tserver
Reporter: Mark Owens
Fix For: 2.0.0
Add capability to add table splits at table creation. Recent changes now allow
iterator and locality groups to be created at table creation. Do the same with
splits. Comment below from
[ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains
the motivation for the request:
{quote}[~etcoleman] added a comment - 2 hours ago
It would go al long way if the splits could be added at table creation or when
table is offline. When the other API changes were made by Mark, I wondered if
this task could also could be done at that time - but I believe that it was
more complicated.
The delay is that when a table is created and then the splits added and then
taken offline there is a period proportional to the number of splits as they
are off-loaded from the tserver where they originally got assigned. (The
re-online with splits distributed across the cluster is quite fast)
If the splits could be added at table creation, or while the table is offline
so that the delay for shedding the tablets could be avoided, then the need to
perform the actual import offline would not be as necessary.
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ACCUMULO-4807) Provide means to determine if bulk import was successful
Mark Owens created ACCUMULO-4807: Summary: Provide means to determine if bulk import was successful Key: ACCUMULO-4807 URL: https://issues.apache.org/jira/browse/ACCUMULO-4807 Project: Accumulo Issue Type: Sub-task Components: master, tserver Reporter: Mark Owens Fix For: 2.0.0 One thing customers would like to be able to do is know whether a bulk import that was launched was successful. If a client launches a bulk import and then dies (a rare case, but it happens), there's no way to know if that bulk import completed or is still in progress. Possibly, if bulk import returned a transaction ID, they'd be able to inquire whether that transaction has completed. Not sure if think that's currently possible via the java client, but operators do consistently monitor FATEs via the shell. It'd be nice to do that via the java client so we can monitor programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens updated ACCUMULO-4806: - Component/s: tserver master > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4806) Allow offline bulk imports
Mark Owens created ACCUMULO-4806: Summary: Allow offline bulk imports Key: ACCUMULO-4806 URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 Project: Accumulo Issue Type: Sub-task Reporter: Mark Owens Fix For: 2.0.0 Allowing offline bulk imports would be useful for some customers. Currently these customers already take tables offline to set split points but then have to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4772) Update Accumulo shell to utilize new NewTableConfiguration methods
[ https://issues.apache.org/jira/browse/ACCUMULO-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4772. -- Resolution: Resolved > Update Accumulo shell to utilize new NewTableConfiguration methods > -- > > Key: ACCUMULO-4772 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4772 > Project: Accumulo > Issue Type: Improvement > Components: shell >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > ACCUMULO-4732 adds the capability for NewTableConfiguration to preconfigure > iterators and locality groups prior to table creation. Update the Accumulo > shell to allow the same capability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4793) Prioritize/Reprioritize bulk import requests
[ https://issues.apache.org/jira/browse/ACCUMULO-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349290#comment-16349290 ] Mark Owens commented on ACCUMULO-4793: -- It is a sub-task. 4793-4796 are sub-tasks of the overriding 4355 ticket. I broke out the four individual requests into separate sub-task tickets. I copy and pasted much of the text from 4355 into each ticket for background. > Prioritize/Reprioritize bulk import requests > > > Key: ACCUMULO-4793 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4793 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Priority: Major > > Accumulo currently provides mechanisms to initiate bulk imports and to list > bulk imports in progress. Scheduling of bulk import requests is not entirely > deterministic, and most of the execution of a bulk-import request is done in > a non-preemptable manner. As such, any bulk import which takes very long to > complete can block bulk imports with higher operational priority for > significant periods. > To better support bulk-import-heavy applications, it would be nice if > Accumulo would offer additional mechanisms for controlling the scheduling and > execution of bulk imports. > One such capability would be the ability to prioritize and re-prioritize bulk > import requests. Recent discussions with customers reveal this to be the > highest priority on their feature request wish list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4355) Provide more granular control for bulk import operations
[
https://issues.apache.org/jira/browse/ACCUMULO-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349130#comment-16349130
]
Mark Owens commented on ACCUMULO-4355:
--
Broke out the various feature requests into sub-task of this ticket.
> Provide more granular control for bulk import operations
>
>
> Key: ACCUMULO-4355
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4355
> Project: Accumulo
> Issue Type: Wish
> Components: master, tserver
>Reporter: Shawn Walker
>Assignee: Shawn Walker
>Priority: Major
> Fix For: 2.0.0
>
>
> Accumulo currently provides mechanisms to initiate bulk imports and to list
> bulk imports in progress. Scheduling of bulk import requests is not entirely
> deterministic, and most of the execution of a bulk-import request is done in
> a non-preemptable manner. As such, any bulk import which takes very long to
> complete can block bulk imports with higher operational priority for
> significant periods.
> To better support bulk-import-heavy applications, it would be nice if
> Accumulo would offer additional mechanisms for controlling the scheduling and
> execution of bulk imports, such as the abilities to:
> * Pause/resume bulk import in progress.
> * Prioritize/reprioritize bulk import requests.
> * Cancel bulk import in progress. If possible, cancelling a partially
> completed bulk import request should result in a rollback of changes. That
> is, a bulk import should either succeed or make no changes.
> Additionally, for multitenant situations, it would be nice if Accumulo would:
> * Provide multiple queues for bulk import requests. Each queue would have
> its requests worked serially in priority order. Requests in separate queues
> should be worked in parallel, or have time distributed among the queues in
> some manner as to make work appear roughly parallel.
>
> Implementation-wise, I'm thinking of rewriting much of the current
> bulk-loading logic. While the current logic depends upon multiple threads
> executing (potentially long-duration) blocking RPC calls, I'd like to move to
> a more event-driven/message-passing model backed by a persistent state
> machine.
> Current ideas I'm playing around with (very tentative)
> * Creating a new table {{accumulo.bulk_load_queues}} to keep track of bulk
> load progress.
> * Distributing bulk load orchestration via a mechanism similar to tablet
> assignment instead of the current blocking RPC calls (LoadFiles.java:156).
> * Implementing something akin to a two-phase commit to achieve rollback
> behavior on failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ACCUMULO-4796) Provide multiple queues for bulk import requests
Mark Owens created ACCUMULO-4796: Summary: Provide multiple queues for bulk import requests Key: ACCUMULO-4796 URL: https://issues.apache.org/jira/browse/ACCUMULO-4796 Project: Accumulo Issue Type: Sub-task Components: master, tserver Reporter: Mark Owens On multi tenant situations, it would be nice if Accumulo would provide multiple queues for bulk import requests. Each queue would have its requests worked serially in priority order. Requests in separate queues should be worked in parallel, or have time distributed among the queues in some manner as to make work appear roughly parallel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4795) cancel bulk import in progress
Mark Owens created ACCUMULO-4795: Summary: cancel bulk import in progress Key: ACCUMULO-4795 URL: https://issues.apache.org/jira/browse/ACCUMULO-4795 Project: Accumulo Issue Type: Sub-task Components: master, tserver Reporter: Mark Owens Accumulo currently provides mechanisms to initiate bulk imports and to list bulk imports in progress. Scheduling of bulk import requests is not entirely deterministic, and most of the execution of a bulk-import request is done in a non-preemptable manner. As such, any bulk import which takes very long to complete can block bulk imports with higher operational priority for significant periods. To better support bulk-import-heavy applications, it would be nice if Accumulo would offer additional mechanisms for controlling the scheduling and execution of bulk imports One such feature would be the ability to cancel bulk import in progress. If possible, canceling a partially completed bulk import request should result in a rollback of changes. That is, a bulk import should either succeed or make no changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4794) Pause/resume in-progress bulk imports
Mark Owens created ACCUMULO-4794: Summary: Pause/resume in-progress bulk imports Key: ACCUMULO-4794 URL: https://issues.apache.org/jira/browse/ACCUMULO-4794 Project: Accumulo Issue Type: Sub-task Components: master, tserver Reporter: Mark Owens Accumulo currently provides mechanisms to initiate bulk imports and to list bulk imports in progress. Scheduling of bulk import requests is not entirely deterministic, and most of the execution of a bulk-import request is done in a non-preemptable manner. As such, any bulk import which takes very long to complete can block bulk imports with higher operational priority for significant periods. To better support bulk-import-heavy applications, it would be nice if Accumulo would offer additional mechanisms for controlling the scheduling and execution of bulk imports The ability to pause in-progress bulk imports and then rresume them is desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4793) Prioritize/Reprioritize bulk import requests
Mark Owens created ACCUMULO-4793: Summary: Prioritize/Reprioritize bulk import requests Key: ACCUMULO-4793 URL: https://issues.apache.org/jira/browse/ACCUMULO-4793 Project: Accumulo Issue Type: Sub-task Components: master, tserver Reporter: Mark Owens Accumulo currently provides mechanisms to initiate bulk imports and to list bulk imports in progress. Scheduling of bulk import requests is not entirely deterministic, and most of the execution of a bulk-import request is done in a non-preemptable manner. As such, any bulk import which takes very long to complete can block bulk imports with higher operational priority for significant periods. To better support bulk-import-heavy applications, it would be nice if Accumulo would offer additional mechanisms for controlling the scheduling and execution of bulk imports. One such capability would be the ability to prioritize and re-prioritize bulk import requests. Recent discussions with customers reveal this to be the highest priority on their feature request wish list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4791) setshelliter command has incorrect usage statement
Mark Owens created ACCUMULO-4791: Summary: setshelliter command has incorrect usage statement Key: ACCUMULO-4791 URL: https://issues.apache.org/jira/browse/ACCUMULO-4791 Project: Accumulo Issue Type: Bug Components: shell Reporter: Mark Owens Fix For: 1.9.0, 2.0.0 When using the Accumulo shell, the setshelliter command should not require a table name and the usage indicates that a table name is optional, as expected. But the command will fail unless an existing table name is supplied. Most likely due to the fact that setshelliter extends setiter, which does require a valid table name. The setshelliter command should be updated to work as the current usage indicates, i.e., no table name should be required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-3361) CryptoTest creates files in /tmp/tmp/
[
https://issues.apache.org/jira/browse/ACCUMULO-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-3361:
Assignee: Mark Owens
> CryptoTest creates files in /tmp/tmp/
> -
>
> Key: ACCUMULO-3361
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3361
> Project: Accumulo
> Issue Type: Bug
>Reporter: Christopher Tubbs
>Assignee: Mark Owens
>Priority: Major
>
> The CryptoTest creates files {{/tmp/tmp/test.secret.key}} and
> {{/tmp/tmp/.test.secret.key.crc}}. It should be creating these files in
> {{target/}} instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4780) Add overflow check to sequence number in CommitSession
[ https://issues.apache.org/jira/browse/ACCUMULO-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4780: Assignee: Mark Owens > Add overflow check to sequence number in CommitSession > -- > > Key: ACCUMULO-4780 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4780 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Keith Turner >Assignee: Mark Owens >Priority: Major > > CommitSession has an integer sequence number that could possibly overflow if > a tablet does 1 billion minor compactions on the same tablet server. It > would be nice to either change this to a long or check if the interger has > overflowed after incrementing. This problem was identified while looking int > ACCUMULO-4777, there are some comments there with background information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16320332#comment-16320332
]
Mark Owens edited comment on ACCUMULO-4158 at 1/10/18 2:35 PM:
---
The two summary files are attached to the ticket above.
was (Author: jmark99):
Here are the two summary files that I've created.
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Assignee: Mark Owens
>Priority: Minor
> Attachments: ep-main.summary, ep-tests.summary
>
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Trace 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Fate 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Start 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Core 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
> accumulo-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 595 source files to
>
[jira] [Updated] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4158:
-
Attachment: ep-main.summary
ep-tests.summary
Here are the two summary files that I've created.
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Assignee: Mark Owens
>Priority: Minor
> Attachments: ep-main.summary, ep-tests.summary
>
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Trace 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Fate 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Start 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Core 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
> accumulo-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 595 source files to
> /Users/mjwall/NetBeansProjects/accumulo-mjwall/core/target/classes
>
[jira] [Commented] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16320329#comment-16320329
]
Mark Owens commented on ACCUMULO-4158:
--
[~ctubbsii], I agree that it would best be used as a development tool. I was
interested in seeing what types of issues it would discover. I created a new
maven profile to run error-prone displaying all findings as warnings. I created
a couple of summary files displaying the results that I'll attach in case
anyone is interested in viewing them. There was no editing of bug-issues in
these runs. All issues that error-prone thinks should be examined are displayed.
Some of the warnings such are LongLiteralLowerCaseSuffix, i.e., using capital
'L' for longs, aren't critical but they do add to consistentcy in the look of
the code base. Additionally, for older guys such as myself, whose eyesight is
not what is used to be, using a capital does make parsing the code much easier
:)
If we decided to use an error-prone profile as a dev tool we could come to a
consensus as to how to manage the error-prone bug list. There are options to
display everything as a warning rather than an error, as well as options to
turn off any particular bug-check completely. You can also convert any warning
to error, or vice-versa. It can also be set to ignore issues in generated code.
There is also a feature that allows error-prone to create patches that can be
used to update the code with selected fixes. For instance, for testing
purposes, I ran a patch to add all missing Override annotations to the code. An
error-prone profile could be used to enforce this convention in future code as
this can be flagged as an error, see
(https://issues.apache.org/jira/browse/ACCUMULO-2537).
I've heard of Spotbugs but have not taken a look as of yet. I'll look into it.
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Assignee: Mark Owens
>Priority: Minor
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
[jira] [Assigned] (ACCUMULO-4158) Investigate using Google's error-prone
[
https://issues.apache.org/jira/browse/ACCUMULO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4158:
Assignee: Mark Owens
> Investigate using Google's error-prone
> --
>
> Key: ACCUMULO-4158
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4158
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Michael Wall
>Assignee: Mark Owens
>Priority: Minor
>
> Google has a tool at http://errorprone.info. From that page
> {quote}
> Using Error Prone to augment the compiler’s type analysis, you can catch more
> mistakes before they cost you time, or end up as bugs in production.
> {quote}
> It requires java 1.8. In the top level pom, replacing
> {code:xml}
>
> maven-compiler-plugin
>
> ${java.ver}
> ${java.ver}
> true
> true
> true
>
>
> {code}
> with
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.3
>
> javac-with-errorprone
> true
>
> ${java.ver}
> ${java.ver}
>
> -Xep:ChainingConstructorIgnoresParameter:WARN
> -Xep:LongLiteralLowerCaseSuffix:OFF
> -Xep:SizeGreaterThanOrEqualsZero:WARN
> -Xep:InvalidPatternSyntax:WARN
> -Xep:TryFailThrowable:WARN
> -Xep:NonOverridingEquals:OFF
>
> true
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.0.8
>
>
> org.codehaus.plexus
> plexus-compiler-javac-errorprone
> 2.5
>
>
>
> {code}
> in the 1.6 branch and runing 'mvn compile' yielded the following.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Accumulo Project
> [INFO] Apache Accumulo Trace
> [INFO] Apache Accumulo Fate
> [INFO] Apache Accumulo Start
> [INFO] Apache Accumulo Core
> [INFO] Apache Accumulo Simple Examples
> [INFO] Apache Accumulo Server Base
> [INFO] Apache Accumulo GC Server
> [INFO] Apache Accumulo Master Server
> [INFO] Apache Accumulo Monitor Server
> [INFO] Apache Accumulo Tracer Server
> [INFO] Apache Accumulo Tablet Server
> [INFO] Apache Accumulo MiniCluster
> [INFO] Apache Accumulo Native Libraries
> [INFO] Apache Accumulo Testing
> [INFO] Apache Accumulo Proxy
> [INFO] Apache Accumulo
> [INFO] Apache Accumulo Documentation
> [INFO] Apache Accumulo Maven Plugin
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Project 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Trace 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Fate 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Start 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Apache Accumulo Core 1.6.6-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
> accumulo-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 595 source files to
> /Users/mjwall/NetBeansProjects/accumulo-mjwall/core/target/classes
> /Users/mjwall/NetBeansProjects/accumulo-mjwall/core/src/main/java/org/apache/accumulo/core/data/Value.java:80:
> warning: [ChainingConstructorIgnoresParameter] The called constructor
>
[jira] [Resolved] (ACCUMULO-4528) importtable and exporttable deserve descriptions in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4528. -- Resolution: Fixed > importtable and exporttable deserve descriptions in the user manual > --- > > Key: ACCUMULO-4528 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4528 > Project: Accumulo > Issue Type: Task > Components: docs >Reporter: Josh Elser >Assignee: Mark Owens > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 6.5h > Remaining Estimate: 0h > > The user manual has a section on exporttable in > http://accumulo.apache.org/1.7/accumulo_user_manual.html#_exporting_tables > but this is just a pointer out to a readme file. > We should really make this a proper chapter to avoid making users have two > hops to get to the documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4528) importtable and exporttable deserve descriptions in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16313585#comment-16313585 ] Mark Owens commented on ACCUMULO-4528: -- Thanks Mike. > importtable and exporttable deserve descriptions in the user manual > --- > > Key: ACCUMULO-4528 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4528 > Project: Accumulo > Issue Type: Task > Components: docs >Reporter: Josh Elser >Assignee: Mark Owens > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 6.5h > Remaining Estimate: 0h > > The user manual has a section on exporttable in > http://accumulo.apache.org/1.7/accumulo_user_manual.html#_exporting_tables > but this is just a pointer out to a readme file. > We should really make this a proper chapter to avoid making users have two > hops to get to the documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4528) importtable and exporttable deserve descriptions in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312395#comment-16312395 ] Mark Owens commented on ACCUMULO-4528: -- It should be done. I added a comment to the PR asking [~mikewalch] if there was something remaining to be done, but have not seen a reply as of yet. > importtable and exporttable deserve descriptions in the user manual > --- > > Key: ACCUMULO-4528 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4528 > Project: Accumulo > Issue Type: Task > Components: docs >Reporter: Josh Elser >Assignee: Mark Owens > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > The user manual has a section on exporttable in > http://accumulo.apache.org/1.7/accumulo_user_manual.html#_exporting_tables > but this is just a pointer out to a readme file. > We should really make this a proper chapter to avoid making users have two > hops to get to the documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4528) importtable and exporttable deserve descriptions in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4528: Assignee: Mark Owens > importtable and exporttable deserve descriptions in the user manual > --- > > Key: ACCUMULO-4528 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4528 > Project: Accumulo > Issue Type: Task > Components: docs >Reporter: Josh Elser >Assignee: Mark Owens > Labels: newbie > Fix For: 2.0.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > The user manual has a section on exporttable in > http://accumulo.apache.org/1.7/accumulo_user_manual.html#_exporting_tables > but this is just a pointer out to a readme file. > We should really make this a proper chapter to avoid making users have two > hops to get to the documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4714. -- Resolution: Resolved Closed issue as changes have already been merged. > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4773) Add sanity check to table properties prior to creation of fate operation
Mark Owens created ACCUMULO-4773: Summary: Add sanity check to table properties prior to creation of fate operation Key: ACCUMULO-4773 URL: https://issues.apache.org/jira/browse/ACCUMULO-4773 Project: Accumulo Issue Type: Improvement Components: fate Reporter: Mark Owens Priority: Minor Fix For: 2.0.0 On the server side, table properties could be sanity checked before the fate operation is created. Could be added prior to https://github.com/apache/accumulo/blob/rel/1.8.1/server/master/src/main/java/org/apache/accumulo/master/FateServiceHandler.java#L151 This would prevent situations where user assumes they have set table properties when in fact the table properties are mis-configured and ignored by the fate operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4772) Update Accumulo shell to utilize new NewTableConfiguration methods
Mark Owens created ACCUMULO-4772: Summary: Update Accumulo shell to utilize new NewTableConfiguration methods Key: ACCUMULO-4772 URL: https://issues.apache.org/jira/browse/ACCUMULO-4772 Project: Accumulo Issue Type: Improvement Components: shell Reporter: Mark Owens Assignee: Mark Owens Priority: Minor Fix For: 2.0.0 ACCUMULO-4732 adds the capability for NewTableConfiguration to preconfigure iterators and locality groups prior to table creation. Update the Accumulo shell to allow the same capability. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4747) Create a unified upgrade reference
[ https://issues.apache.org/jira/browse/ACCUMULO-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4747. -- Resolution: Resolved Fix Version/s: 2.0.0 > Create a unified upgrade reference > -- > > Key: ACCUMULO-4747 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4747 > Project: Accumulo > Issue Type: Improvement > Components: docs, website >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Labels: documentation, pull-request-available > Fix For: 2.0.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It could be helpful to have a page which provides upgrade instructions for > the various releases collected into one location. This page could then be > updated as needed as new versions are released. Prompted by someone needing > to upgrade for 1.4 to 1.8 and looking for a good location to find what steps > would be needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4747) Create a unified upgrade reference
[ https://issues.apache.org/jira/browse/ACCUMULO-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280047#comment-16280047 ] Mark Owens commented on ACCUMULO-4747: -- I think it is complete for now. I will close it out. Once the 2.0 docs are officially released we will revisit the issue to address some of the concerns mentioned in the comments on GitHub. > Create a unified upgrade reference > -- > > Key: ACCUMULO-4747 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4747 > Project: Accumulo > Issue Type: Improvement > Components: docs, website >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Labels: documentation, pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > It could be helpful to have a page which provides upgrade instructions for > the various releases collected into one location. This page could then be > updated as needed as new versions are released. Prompted by someone needing > to upgrade for 1.4 to 1.8 and looking for a good location to find what steps > would be needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4747) Create a unified upgrade reference
[ https://issues.apache.org/jira/browse/ACCUMULO-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4747: Assignee: Mark Owens > Create a unified upgrade reference > -- > > Key: ACCUMULO-4747 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4747 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Mark Owens >Assignee: Mark Owens >Priority: Minor > Labels: documentation > > It could be helpful to have a page which provides upgrade instructions for > the various releases collected into one location. This page could then be > updated as needed as new versions are released. Prompted by someone needing > to upgrade for 1.4 to 1.8 and looking for a good location to find what steps > would be needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4546) IllegalTableTransitionException should include a default message that logs the requested state transition
[ https://issues.apache.org/jira/browse/ACCUMULO-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4546: Assignee: Mark Owens > IllegalTableTransitionException should include a default message that logs > the requested state transition > - > > Key: ACCUMULO-4546 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4546 > Project: Accumulo > Issue Type: Bug > Components: server-base >Affects Versions: 1.6.6 >Reporter: John Vines >Assignee: Mark Owens > Fix For: 1.7.4, 1.8.2, 2.0.0 > > > While trying to track down the root of an Illegal state transition for a > table, I hit a dead end when the original transition to bring a table online > failed. The IllegalTableTransitionException takes in the old and new states > in the contstructor for the exception, but these states are not used to > construct any sort of message, so this information isn't available in the > logs. We should have a default message for this constructor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4732) No APIs to configure iterators and locality groups for new table
[ https://issues.apache.org/jira/browse/ACCUMULO-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4732: Assignee: Mark Owens > No APIs to configure iterators and locality groups for new table > > > Key: ACCUMULO-4732 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4732 > Project: Accumulo > Issue Type: Improvement >Reporter: Keith Turner >Assignee: Mark Owens >Priority: Major > Labels: newbie > Fix For: 2.0.0 > > > In Accumulo 1.7 the ability to set table properties at table creation time > was added. For existing tables there are APIs in table operations that allow > setting locality groups and iterators for existing tables. When setting > table properties at table creation time there is not good API for iterators > and locality groups. There should be some way in the API to do this. There > may be other things besides iterators and locality groups that should also be > supported at table creation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223176#comment-16223176 ] Mark Owens commented on ACCUMULO-4714: -- That was my thought as well. I hope to organize the information that I have repeatedly referred back to as I’ve gotten started with the project. I’ll definitely week out assistance as I go along. > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4714: Assignee: Mark Owens > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4721) Document rfile-info in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-4721. -- Resolution: Fixed > Document rfile-info in the user manual > -- > > Key: ACCUMULO-4721 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4721 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Michael Wall >Assignee: Mark Owens >Priority: Trivial > Labels: pull-request-available > Fix For: 1.7.4, 1.8.2, 2.0.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the 'old school' PrintInfo is documented at > http://accumulo.apache.org/1.8/accumulo_user_manual.html#_tools > We should document the 'rfile-info' info which is easier to remember than > org.apache.accumulo.core.file.rfile.PrintInfo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4721) Document rfile-info in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4721: Assignee: Mark Owens > Document rfile-info in the user manual > -- > > Key: ACCUMULO-4721 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4721 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Michael Wall >Assignee: Mark Owens >Priority: Trivial > Fix For: 1.7.4, 1.8.2, 2.0.0 > > > Currently the 'old school' PrintInfo is documented at > http://accumulo.apache.org/1.8/accumulo_user_manual.html#_tools > We should document the 'rfile-info' info which is easier to remember than > org.apache.accumulo.core.file.rfile.PrintInfo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4722) Use Objects.equal in Pair equals method
[
https://issues.apache.org/jira/browse/ACCUMULO-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4722:
Assignee: Mark Owens
> Use Objects.equal in Pair equals method
> ---
>
> Key: ACCUMULO-4722
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4722
> Project: Accumulo
> Issue Type: Improvement
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie
> Fix For: 2.0.0
>
>
> I think {{org.apache.accumulo.core.util.Pair.equals()}} could call
> {{Objects.equal()}} and the private internal method that does and equality
> check could be dropped. Need to verify the changes will have the same
> behavior for null.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202825#comment-16202825
]
Mark Owens commented on ACCUMULO-4716:
--
Closed and fix versions updated. Thanks [~ctubbsii]
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4716.
--
Resolution: Fixed
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4716:
-
Fix Version/s: 2.0.0
1.8.2
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4716:
-
Fix Version/s: 1.7.4
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4170) ClientConfiguration javadoc difficult to read
[ https://issues.apache.org/jira/browse/ACCUMULO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-4170: Assignee: Mark Owens > ClientConfiguration javadoc difficult to read > - > > Key: ACCUMULO-4170 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4170 > Project: Accumulo > Issue Type: Bug > Components: client, docs >Affects Versions: 1.7.1 >Reporter: Mike Drob >Assignee: Mark Owens >Priority: Trivial > Labels: newbie > > The docs displayed on > https://accumulo.apache.org/1.7/apidocs/org/apache/accumulo/core/client/ClientConfiguration.html#loadDefault%28%29 > are difficult to read because the list is displayed in-line. We could use > proper list formatting to improve readability. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200425#comment-16200425
]
Mark Owens edited comment on ACCUMULO-4561 at 10/11/17 5:51 PM:
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{noformat}
TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
44263/tcp open httpJetty 6.1.26
50070/tcp open httpJetty 6.1.26
50090/tcp open httpJetty 6.1.26
>>> #
>>> # java.lang.OutOfMemoryError: Java heap space
>>> # -XX:OnOutOfMemoryError="kill -9 %p"
>>> # Executing /bin/sh -c "kill -9 7693"...
>>> Killed
This port returned a different response after a timeout:
50075/tcp open httpJetty 6.1.26
>>> localhost:50075 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:37190
>>> remote=localhost/127.0.0.1:50075]
{noformat}
I have no feel for how often the 'ping -ts ' command is run and how often
it would be provided an invalid port? I would assume a user would only supply a
port if they suspected it to be a tserver. Given that case this situation would
not happen very often, I suspect.
I also noticed that if I stop the tablet servers after I'm in the shell and
then run the ping command, the shell never returns the prompt to the user.
Ctrl-C'ing at that points exits the shell as well. I would think that should
be fixed since the purpose of the ping is to retrieve the status of a tablet
server. Has that behavior been documented and/or verified previously?
was (Author: jmark99):
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open http
[jira] [Commented] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200641#comment-16200641
]
Mark Owens commented on ACCUMULO-4561:
--
A little more info: The monitor.log returns the following warning when the
ping command targets a Jetty port:
{noformat}
2017-10-11 13:09:25,039 [http.HttpParser] WARN : Illegal character 0x0 in
state=START for buffer
HeapByteBuffer@3249e354[p=1,l=179,c=8192,r=178]={\x00<<<\x00\x00\xAf\x82!\x01\x15getTabletS...d92138d\x00,\x16\x00\x16\x00\x00\x00>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
2017-10-11 13:09:25,039 [http.HttpParser] WARN : bad HTTP parsed: 400 Illegal
character 0x0 for HttpChannelOverHttp@4676385e{r=0,c=false,a=IDLE,uri=null}
{noformat}
The returned HTTP payload (via wireshark) is:
{noformat}
48 54 54 50 2f 31 2e 31 20 34 30 30 20 49 6c 6c HTTP/1.1 400 Ill
0010 65 67 61 6c 20 63 68 61 72 61 63 74 65 72 20 30 egal character 0
0020 78 30 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 x0..Content-Leng
0030 74 68 3a 20 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f th: 0..Connectio
0040 6e 3a 20 63 6c 6f 73 65 0d 0a 53 65 72 76 65 72 n: close..Server
0050 3a 20 4a 65 74 74 79 28 39 2e 33 2e 32 31 2e 76 : Jetty(9.3.21.v
0060 32 30 31 37 30 39 31 38 29 0d 0a 0d 0a 20170918)
{noformat}
> Crash when using ping on a non-existing server
> --
>
> Key: ACCUMULO-4561
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4561
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Luis Tavarez
>
> While working on ACCUMULO-4558, I tried running
> {code}ping -ts localhost:9995{code} (localhost:9995 does not have a a tserver
> on my setup.)
> And it caused the shell to exit (crashed) and show the following message.
> {code}#
> # java.lang.OutOfMemoryError: Java heap space
> # -XX:OnOutOfMemoryError="kill -9 %p"
> # Executing /bin/sh -c "kill -9 25561"...
> /home/lmtavar/git/uno/bin/uno: line 44: 25561 Killed
> "$ACCUMULO_HOME"/bin/accumulo shell -u "$ACCUMULO_USER" -p
> "$ACCUMULO_PASSWORD" "${@:2}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200425#comment-16200425
]
Mark Owens edited comment on ACCUMULO-4561 at 10/11/17 3:10 PM:
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
44263/tcp open httpJetty 6.1.26
50070/tcp open httpJetty 6.1.26
50090/tcp open httpJetty 6.1.26
>>> #
>>> # java.lang.OutOfMemoryError: Java heap space
>>> # -XX:OnOutOfMemoryError="kill -9 %p"
>>> # Executing /bin/sh -c "kill -9 7693"...
>>> Killed
This port returned a different response after a timeout:
50075/tcp open httpJetty 6.1.26
>>> localhost:50075 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:37190
>>> remote=localhost/127.0.0.1:50075]}}
I have no feel for how often the 'ping -ts ' command is run and how often
it would be provided an invalid port? I would assume a user would only supply a
port if they suspected it to be a tserver. Given that case this situation would
not happen very often, I suspect.
I also noticed that if I stop the tablet servers after I'm in the shell and
then run the ping command, the shell never returns the prompt to the user.
Ctrl-C'ing at that points exits the shell as well. I would think that should
be fixed since the purpose of the ping is to retrieve the status of a tablet
server. Has that behavior been documented and/or verified previously?
was (Author: jmark99):
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
[jira] [Comment Edited] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200425#comment-16200425
]
Mark Owens edited comment on ACCUMULO-4561 at 10/11/17 3:10 PM:
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
44263/tcp open httpJetty 6.1.26
50070/tcp open httpJetty 6.1.26
50090/tcp open httpJetty 6.1.26
>>> #
>>> # java.lang.OutOfMemoryError: Java heap space
>>> # -XX:OnOutOfMemoryError="kill -9 %p"
>>> # Executing /bin/sh -c "kill -9 7693"...
>>> Killed
This port returned a different response after a timeout:
50075/tcp open httpJetty 6.1.26
>>> localhost:50075 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:37190
>>> remote=localhost/127.0.0.1:50075]
I have no feel for how often the 'ping -ts ' command is run and how often
it would be provided an invalid port? I would assume a user would only supply a
port if they suspected it to be a tserver. Given that case this situation would
not happen very often, I suspect.
I also noticed that if I stop the tablet servers after I'm in the shell and
then run the ping command, the shell never returns the prompt to the user.
Ctrl-C'ing at that points exits the shell as well. I would think that should
be fixed since the purpose of the ping is to retrieve the status of a tablet
server. Has that behavior been documented and/or verified previously?
was (Author: jmark99):
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
[jira] [Commented] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200425#comment-16200425
]
Mark Owens commented on ACCUMULO-4561:
--
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{
TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
44263/tcp open httpJetty 6.1.26
50070/tcp open httpJetty 6.1.26
50090/tcp open httpJetty 6.1.26
>>> #
>>> # java.lang.OutOfMemoryError: Java heap space
>>> # -XX:OnOutOfMemoryError="kill -9 %p"
>>> # Executing /bin/sh -c "kill -9 7693"...
>>> Killed
This port returned a different response after a timeout:
50075/tcp open httpJetty 6.1.26
>>> localhost:50075 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:37190
>>> remote=localhost/127.0.0.1:50075]
}}
I have no feel for how often the 'ping -ts ' command is run and how often
it would be provided an invalid port? I would assume a user would only supply a
port if they suspected it to be a tserver. Given that case this situation would
not happen very often, I suspect.
I also noticed that if I stop the tablet servers after I'm in the shell and
then run the ping command, the shell never returns the prompt to the user.
Ctrl-C'ing at that points exits the shell as well. I would think that should
be fixed since the purpose of the ping is to retrieve the status of a tablet
server. Has that behavior been documented and/or verified previously?
> Crash when using ping on a non-existing server
> --
>
> Key: ACCUMULO-4561
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4561
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Luis Tavarez
>
> While working on ACCUMULO-4558, I tried running
> {code}ping -ts localhost:9995{code} (localhost:9995 does not have a a tserver
> on my setup.)
> And it caused the shell to exit (crashed) and show the following message.
> {code}#
> # java.lang.OutOfMemoryError: Java heap space
> # -XX:OnOutOfMemoryError="kill -9 %p"
> # Executing /bin/sh -c "kill -9 25561"...
> /home/lmtavar/git/uno/bin/uno: line 44: 25561 Killed
> "$ACCUMULO_HOME"/bin/accumulo shell -u "$ACCUMULO_USER" -p
> "$ACCUMULO_PASSWORD" "${@:2}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ACCUMULO-4561) Crash when using ping on a non-existing server
[
https://issues.apache.org/jira/browse/ACCUMULO-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200425#comment-16200425
]
Mark Owens edited comment on ACCUMULO-4561 at 10/11/17 3:09 PM:
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty 9.3.21.v20170918
44263/tcp open httpJetty 6.1.26
50070/tcp open httpJetty 6.1.26
50090/tcp open httpJetty 6.1.26
>>> #
>>> # java.lang.OutOfMemoryError: Java heap space
>>> # -XX:OnOutOfMemoryError="kill -9 %p"
>>> # Executing /bin/sh -c "kill -9 7693"...
>>> Killed
This port returned a different response after a timeout:
50075/tcp open httpJetty 6.1.26
>>> localhost:50075 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:37190
>>> remote=localhost/127.0.0.1:50075]}}
I have no feel for how often the 'ping -ts ' command is run and how often
it would be provided an invalid port? I would assume a user would only supply a
port if they suspected it to be a tserver. Given that case this situation would
not happen very often, I suspect.
I also noticed that if I stop the tablet servers after I'm in the shell and
then run the ping command, the shell never returns the prompt to the user.
Ctrl-C'ing at that points exits the shell as well. I would think that should
be fixed since the purpose of the ping is to retrieve the status of a tablet
server. Has that behavior been documented and/or verified previously?
was (Author: jmark99):
These crashes appear to be occurring when sending a ping request to ports that
have Jetty listening. I ran an nmap scan on my local machine looking for open
ports and then ran the accumulo shell ping command against the open ports
(closed ports return connection refused).
Note that all these tests were run on the 2.0.0-SNAPSHOT.
My results are listed below:
{{
TServer port on local instance:
9997/tcp open palace-6?
>>> localhost:9997:OK
Following ports all returned same response:
2181/tcp open eforward?
4560/tcp open unknown
5355/tcp open llmnr?
8030/tcp open hadoop-ipc Hadoop IPC
8031/tcp open hadoop-ipc Hadoop IPC
8032/tcp open hadoop-ipc Hadoop IPC
8033/tcp open hadoop-ipc Hadoop IPC
8040/tcp open hadoop-ipc Hadoop IPC
9000/tcp open hadoop-ipc Hadoop IPC
34737/tcp open unknown
39473/tcp open hadoop-ipc Hadoop IPC
50010/tcp open unknown
50020/tcp open hadoop-ipc Hadoop IPC
>>> localhost:8031 ERROR org.apache.thrift.transport.TTransportException
9998/tcp open distinct32?
/tcp open abyss?
10001/tcp open scp-config?
>>> localhost:9998 ERROR org.apache.thrift.TApplicationException: Invalid
>>> method name: 'getTabletServerStatus'
13562/tcp open unknown
>>> localhost:13562 ERROR org.apache.thrift.transport.TTransportException:
>>> java.net.SocketTimeoutException: 12 millis timeout while waiting for
>>> channel to be ready for read. ch :
>>> java.nio.channels.SocketChannel[connected local=/127.0.0.1:36716
>>> remote=localhost/127.0.0.1:13562]
Jetty ports:
8042/tcp open httpJetty 6.1.26
8088/tcp open httpJetty 6.1.26
9995/tcp open httpJetty
[jira] [Updated] (ACCUMULO-3329) Consider consolidation of "timing" classes
[ https://issues.apache.org/jira/browse/ACCUMULO-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens updated ACCUMULO-3329: - Description: We have a number of "timing" classes in or used by the codebase * org.apache.accumulo.core.util.StopWatch * org.apache.accumulo.core.util.OpTimer * Traces * Guava's Stopwatch I'm assuming that consolidation of all of the timings into Traces would be the best (assuming that if we care about the timing of a given operation implies that twe would also care about the timing of the "bigger picture"). If we can remove some of our timer classes, that would be great. Not suggesting that we forcibly prevent the use of Stopwatches/TImers in the codebase entirely -- just where it makes sense. was: We have a number of "timing" classes in or used by the codebase * org.apache.accumulo.core.util.StopWatch * org.apache.accumulo.core.util.OpTimer * Traces * Guava's Stopwatch I'm assuming that consolidation of all of the timings into Traces would be the best (assuming that if we care about the timing of a given operation implies that we would also care about the timing of the "bigger picture"). If we can remove some of our timer classes, that would be great. Not suggesting that we forcibly prevent the use of Stopwatches/TImers in the codebase entirely -- just where it makes sense. > Consider consolidation of "timing" classes > -- > > Key: ACCUMULO-3329 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3329 > Project: Accumulo > Issue Type: Improvement > Components: client, master, tserver >Reporter: Josh Elser > Labels: newbie > Fix For: 2.0.0 > > > We have a number of "timing" classes in or used by the codebase > * org.apache.accumulo.core.util.StopWatch > * org.apache.accumulo.core.util.OpTimer > * Traces > * Guava's Stopwatch > I'm assuming that consolidation of all of the timings into Traces would be > the best (assuming that if we care about the timing of a given operation > implies that twe would also care about the timing of the "bigger picture"). > If we can remove some of our timer classes, that would be great. Not > suggesting that we forcibly prevent the use of Stopwatches/TImers in the > codebase entirely -- just where it makes sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-2968) axe TabletServer.majorCompactorDisabled
[ https://issues.apache.org/jira/browse/ACCUMULO-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens resolved ACCUMULO-2968. -- Resolution: Resolved Fix Version/s: 2.0.0 > axe TabletServer.majorCompactorDisabled > --- > > Key: ACCUMULO-2968 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2968 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Adam Fuchs >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > TabletServer.majorCompactorDisabled is a constant false and has no value. > Give it the chop. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4716:
Assignee: Mark Owens
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4516) TeraSortIngest splits argument is ignored if less than 10 arguments are provided
[
https://issues.apache.org/jira/browse/ACCUMULO-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4516.
--
Resolution: Resolved
Updated merged into master: https://github.com/apache/accumulo-examples/pull/6
> TeraSortIngest splits argument is ignored if less than 10 arguments are
> provided
>
>
> Key: ACCUMULO-4516
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4516
> Project: Accumulo
> Issue Type: Bug
> Components: examples
>Reporter: Josh Elser
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I invoked the TeraSortIngest and did not see my table being pre-split:
> {noformat}
> tool.sh lib/accumulo-examples-simple.jar
> org.apache.accumulo.examples.simple.mapreduce.TeraSortIngest -i accumulo -z
> jelser-accumulo-scripts-1 -u root -p secret --count $((1000 * 1000 * 50))
> --minKeySiz
> e 10 --maxKeySize 10 --minValueSize 78 --maxValueSize 78 --table terasort
> --splits 15
> {noformat}
> Turns out that the positional argument parsing got lost in the switch to
> jcommander:
> {code}
> if (args.length > 10)
> conf.setInt(NUMSPLITS, opts.splits);
> {code}
> We should just set this value if the value for {{splits}} is not the default
> (0).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-2968) axe TabletServer.majorCompactorDisabled
[ https://issues.apache.org/jira/browse/ACCUMULO-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-2968: Assignee: Mark Owens > axe TabletServer.majorCompactorDisabled > --- > > Key: ACCUMULO-2968 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2968 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Adam Fuchs >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > TabletServer.majorCompactorDisabled is a constant false and has no value. > Give it the chop. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4516) TeraSortIngest splits argument is ignored if less than 10 arguments are provided
[
https://issues.apache.org/jira/browse/ACCUMULO-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens reassigned ACCUMULO-4516:
Assignee: Mark Owens
> TeraSortIngest splits argument is ignored if less than 10 arguments are
> provided
>
>
> Key: ACCUMULO-4516
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4516
> Project: Accumulo
> Issue Type: Bug
> Components: examples
>Reporter: Josh Elser
>Assignee: Mark Owens
> Labels: newbie
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
>
> I invoked the TeraSortIngest and did not see my table being pre-split:
> {noformat}
> tool.sh lib/accumulo-examples-simple.jar
> org.apache.accumulo.examples.simple.mapreduce.TeraSortIngest -i accumulo -z
> jelser-accumulo-scripts-1 -u root -p secret --count $((1000 * 1000 * 50))
> --minKeySiz
> e 10 --maxKeySize 10 --minValueSize 78 --maxValueSize 78 --table terasort
> --splits 15
> {noformat}
> Turns out that the positional argument parsing got lost in the switch to
> jcommander:
> {code}
> if (args.length > 10)
> conf.setInt(NUMSPLITS, opts.splits);
> {code}
> We should just set this value if the value for {{splits}} is not the default
> (0).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183239#comment-16183239 ] Mark Owens commented on ACCUMULO-2907: -- Replaced use of StringBuilder with String. > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183143#comment-16183143 ] Mark Owens commented on ACCUMULO-2907: -- The pull request has been updated to only display the security warning message when appropriate and as described in the previous comments. > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie, pull-request-available > Fix For: 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16181012#comment-16181012 ] Mark Owens commented on ACCUMULO-2907: -- Is inspecting the value of the *Property.INSTANCE_SECURITY_AUTHENTICATOR* value a sufficient condition for determining the type of authentication used? If it uses the ZKAuthenticator should we suppress the message assuming a root password is needed and for all other authenticators leave the message in place? > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie > Fix For: 2.0.0 > > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178857#comment-16178857 ] Mark Owens commented on ACCUMULO-2907: -- Thanks for the input. Inspecting the authenticator configuration key sounds like a good idea. I will update the change to take that into account. > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175711#comment-16175711 ] Mark Owens commented on ACCUMULO-2907: -- Hi [~ctubbsii], Thanks for the comment. I proceeded with the change based on the comment from [~elserj] above where he stated it was completely irrelevant given prior comments. If that is not the case I'm willing to take a deeper look into the issue, although I'm sure I would need some assistance given that I'm just getting into the code base. > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens updated ACCUMULO-2907: - Summary: Invalidate "this may not be applicable for your security setup" warning from initialize (was: Invalidate "this may not be applicable for your security setup" warning from initialize) > Invalidate "this may not be applicable for your security setup" warning from > initialize > > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-2907) Invalidate "this may not be applicable for your security setup" warning from initialize
[ https://issues.apache.org/jira/browse/ACCUMULO-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Owens reassigned ACCUMULO-2907: Assignee: Mark Owens > Invalidate "this may not be applicable for your security setup" warning from > initialize > --- > > Key: ACCUMULO-2907 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2907 > Project: Accumulo > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Mark Owens >Priority: Minor > Labels: newbie > > The warning that is printed about setting a root password may not be > applicable for your security setup is invalid because the plugable > authentication modules do not manage the root user and it is expected that > there will always be a local root user with a password. > Remove the warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
