[jira] [Commented] (ACCUMULO-2113) Verify that The Hammer approach to resource leak is a viable short term fix
[ https://issues.apache.org/jira/browse/ACCUMULO-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859398#comment-13859398 ] Jared Winick commented on ACCUMULO-2113: This needs to be cleaned up a bit and posted as a patch but I wanted to make the code available for review. To make my life easier I implemented the proposed ClientThreads within my test web app at https://github.com/jaredwinick/accumulo-1858-test/blob/ACCUMULO-2113/src/main/java/org/apache/accumulo/core/util/ClientThreads.java This current version is built and was tested against 1.4.3 but with minor refactoring should apply to all versions. I will attach the graph from VisualVM that shows that it works just like the other solution documented in ACCUMULO-1858. Since the implementation forcefully stops the ThriftTransportPool thread, I initially thought I would try the same for the Zookeeper threads. It turned out that ZK is resilient and appeared to handle the ThreadDeath and recover, so I opted for the more graceful shutdown of the ZooKeepers. > Verify that The Hammer approach to resource leak is a viable short term fix > --- > > Key: ACCUMULO-2113 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2113 > Project: Accumulo > Issue Type: Task >Affects Versions: 1.4.5, 1.5.1, 1.6.0 >Reporter: Sean Busbey >Assignee: Jared Winick >Priority: Blocker > Fix For: 1.4.5, 1.5.1, 1.6.0 > > Attachments: ACCUMULO-2113-ResourceGraph.png > > > ACCUMULO-1858 contains a link to a test harness for verifying that we aren't > leaking resources in e.g. Tomcat. > We need someone to take "The Hammer" approach [proposed by > Keith|http://mail-archives.apache.org/mod_mbox/accumulo-dev/201312.mbox/%3CCAGUtCHrThjFW-u%2BJK%2BZYALB-qut2VNd5AH1Sb8o7UcQFUXM4xA%40mail.gmail.com%3E] > and verify that it successfully stops the leak. > Afterwords, results should be linked to on the mailing list so we can come to > consensus on how to handle the API change for releases. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2113) Verify that The Hammer approach to resource leak is a viable short term fix
[ https://issues.apache.org/jira/browse/ACCUMULO-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Winick updated ACCUMULO-2113: --- Attachment: ACCUMULO-2113-ResourceGraph.png > Verify that The Hammer approach to resource leak is a viable short term fix > --- > > Key: ACCUMULO-2113 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2113 > Project: Accumulo > Issue Type: Task >Affects Versions: 1.4.5, 1.5.1, 1.6.0 >Reporter: Sean Busbey >Assignee: Jared Winick >Priority: Blocker > Fix For: 1.4.5, 1.5.1, 1.6.0 > > Attachments: ACCUMULO-2113-ResourceGraph.png > > > ACCUMULO-1858 contains a link to a test harness for verifying that we aren't > leaking resources in e.g. Tomcat. > We need someone to take "The Hammer" approach [proposed by > Keith|http://mail-archives.apache.org/mod_mbox/accumulo-dev/201312.mbox/%3CCAGUtCHrThjFW-u%2BJK%2BZYALB-qut2VNd5AH1Sb8o7UcQFUXM4xA%40mail.gmail.com%3E] > and verify that it successfully stops the leak. > Afterwords, results should be linked to on the mailing list so we can come to > consensus on how to handle the API change for releases. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1989) Can't configure (default) namespace parameters from shell
[ https://issues.apache.org/jira/browse/ACCUMULO-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859265#comment-13859265 ] Chris McCubbin commented on ACCUMULO-1989: -- Yeah, [~vines] and I figured it out after some experimentation. Maybe it could remain as "" if an example is given in the shell help (and maybe in the error message if someone attempts to configure "default") ? > Can't configure (default) namespace parameters from shell > - > > Key: ACCUMULO-1989 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1989 > Project: Accumulo > Issue Type: Bug >Reporter: Chris McCubbin > Fix For: 1.6.0 > > > The shell has a problem with parentheses, this makes it impossible to, e.g. > remove an iterator from the (default) namespace. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1878) Functional test for Examples doesn't check return codes; many examples don't run
[ https://issues.apache.org/jira/browse/ACCUMULO-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859264#comment-13859264 ] Christopher Tubbs commented on ACCUMULO-1878: - Note: A similar issue to this one existed in 1.6.0, where we weren't checking the return codes of ExamplesIT. That was fixed, however. > Functional test for Examples doesn't check return codes; many examples don't > run > > > Key: ACCUMULO-1878 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1878 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.4.5, 1.5.1 > > Attachments: ACCUMULO-1878.1.patch.txt, ACCUMULO-1878.2.patch.txt > > > While investigating a failure on the bloom filter speed test in the > simple.examples.Examples functional test, I found that no data was getting > written in the 1.4.x branch. > After changing things to check return codes be default (so the above would > fail), I found that most of the Examples aren't actually running in 1.4 or > 1.5 because of incorrect class names. > I have most of a fix, just waiting actually run through the fixes and figure > out handling the merge of fixes from 1.4 -> 1.5 -> 1.6. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1988) Example map reduce not running in functional test
[
https://issues.apache.org/jira/browse/ACCUMULO-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859263#comment-13859263
]
Christopher Tubbs commented on ACCUMULO-1988:
-
Note: these are also failing in ExamplesIT in 1.6.0, but the issue of checking
the return code is fixed there.
> Example map reduce not running in functional test
> -
>
> Key: ACCUMULO-1988
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1988
> Project: Accumulo
> Issue Type: Sub-task
> Components: test
>Reporter: Keith Turner
>Assignee: Bill Havanki
> Fix For: 1.5.1
>
>
> While merging fixes for ACCUMULO-1878 from 1.4 to 1.5 I noticed that example
> map reduce jobs were failing and the return code was not checked. Below is
> an example of one of the failing test.
> {noformat}
> $ ./test/system/auto/run.py -t example -v 10
>.
>.
>.
> DEBUG:test.auto:node1:
> /home/kturner/workspace/accumulo-1.5.1-SNAPSHOT/bin/tool.sh
> /home/kturner/workspace/accumulo-1.5.1-SNAPSHOT/lib/accumulo-examples-simple.jar
> org.apache.accumulo.examples.simple.mapreduce.RowHash -i node1-37680 -z
> localhost:2181 -u root -p secret -t sorted --column : sortedHashed
> DEBUG:test.auto:Output from command: Usage:
> org.apache.accumulo.examples.simple.mapreduce.RowHash [options]
> Options:
> -auths, --auths
>the authorizations to use when reading or writing
>Default:
> * --column
>
> --debug
>turn on TRACE-level log messages
>Default: false
> -h, -?, --help, -help
>
>Default: false
> -i, --instance
>The name of the accumulo instance
> -z, --keepers
>Comma separated list of zookeeper hosts (host:port,host:port)
>Default: localhost:2181
> -fake, --mock
>Use a mock Instance
>Default: false
> --password
>Enter the connection password
> --site-file
>Read the given accumulo site file to find the accumulo instance
> * -t, --table
>table to use
> -tc, --tokenClass
>Token class
>Default: org.apache.accumulo.core.client.security.tokens.PasswordToken
> --trace
>turn on distributed tracing
>Default: false
> -u, --user
>Connection user
>Default: kturner
> -l
>login properties in the format key=value. Reuse -l for each property
>(prompt for properties if this option is missing
>Syntax: -lkey=value
>Default: {}
> -p
>Connection password
> INFO:test.auto:Error output from command: Was passed main parameter
> 'sortedHashed' but no main parameter was defined
> DEBUG:test.auto:Exit code: 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1989) Can't configure (default) namespace parameters from shell
[ https://issues.apache.org/jira/browse/ACCUMULO-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859261#comment-13859261 ] Christopher Tubbs commented on ACCUMULO-1989: - The default namespace is the empty string, similar to java's default package. Namespaces allow tables to be fully qualified. So, tables in the default namespace are fully qualified without a namespace prefix. The problem is, that doesn't show up well in the shell when we list namespaces. The string "(default)" was chosen as a placeholder, because we can't show an empty string (Eclipse, and other IDEs do something similar to show the "(default package)"). Do you have a suggestion that is more intuitive? One option might be to have a separate flag "--default-namespace" to expose it more obviously. > Can't configure (default) namespace parameters from shell > - > > Key: ACCUMULO-1989 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1989 > Project: Accumulo > Issue Type: Bug >Reporter: Chris McCubbin > Fix For: 1.6.0 > > > The shell has a problem with parentheses, this makes it impossible to, e.g. > remove an iterator from the (default) namespace. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1993) proxy classes conflict with Ruby system classes
[
https://issues.apache.org/jira/browse/ACCUMULO-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-1993:
Fix Version/s: 1.6.0
> proxy classes conflict with Ruby system classes
> ---
>
> Key: ACCUMULO-1993
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1993
> Project: Accumulo
> Issue Type: Bug
> Components: proxy
>Affects Versions: 1.4.4, 1.5.0
>Reporter: Brian Loss
> Fix For: 1.6.0
>
>
> The proxy declares the Range class, however this class also exists as a Ruby
> system class, which causes problems when attempting to construct ranges.
> Really, all the generated classes for Ruby should be placed in an Accumulo
> namespace. Add the appropriate declaration, such as
> {code}
> namespace rb Accumulo
> {code}
> to the proxy thrift IDL.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1994) proxy does not handle Key timestamps correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-1994:
Fix Version/s: 1.6.0
1.5.1
1.4.5
> proxy does not handle Key timestamps correctly
> --
>
> Key: ACCUMULO-1994
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1994
> Project: Accumulo
> Issue Type: Bug
> Components: proxy
>Affects Versions: 1.4.4, 1.5.0
>Reporter: Brian Loss
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> The proxy thrift IDL does not declare any default values for the Key struct.
> This means that timestamp will default to 0. However, in Java it defaults to
> Long.MAX_VALUE. This means that ranges created through the proxy may behave
> differently than ranges created in Java. For example, say in Ruby I create a
> range as follows
> {code}
> range = Range.new(:start => Key.new(:row => "row1"), :startInclusive => true,
> :stop => Key.new(:row => "row2"), :stopInclusive => true)
> {code}
> This range will not include any keys in row1 that don't have a column family,
> qualifier, or visibility since timestamp of 0 sorts last. If I created the
> same range in Java, those keys would be included.
> Change the thrift IDL to declare 0x7FFF (Long.MAX_VALUE) as the
> default value for timstamp so that the thrift-generated Key class behaves the
> same way as the Java version.
> [~kturner] pointed me to the getRowRange helper method on the AccumuloProxy
> service. This method helps in some cases, but not the case I mentioned above
> since I have two arbitrary rows. Also, in looking through the code in
> ProxyServer, Keith noticed that the code does not seem to handle timestamps
> correctly. For example, the getRowRange method does not pass a timestamp at
> all (not even the EMPTY value). Also, the internal helper method getProxyKey
> ignores the timestamp on the incoming key.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1994) proxy does not handle Key timestamps correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-1994:
Affects Version/s: (was: 1.6.1)
(was: 1.6.0)
> proxy does not handle Key timestamps correctly
> --
>
> Key: ACCUMULO-1994
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1994
> Project: Accumulo
> Issue Type: Bug
> Components: proxy
>Affects Versions: 1.4.4, 1.5.0
>Reporter: Brian Loss
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> The proxy thrift IDL does not declare any default values for the Key struct.
> This means that timestamp will default to 0. However, in Java it defaults to
> Long.MAX_VALUE. This means that ranges created through the proxy may behave
> differently than ranges created in Java. For example, say in Ruby I create a
> range as follows
> {code}
> range = Range.new(:start => Key.new(:row => "row1"), :startInclusive => true,
> :stop => Key.new(:row => "row2"), :stopInclusive => true)
> {code}
> This range will not include any keys in row1 that don't have a column family,
> qualifier, or visibility since timestamp of 0 sorts last. If I created the
> same range in Java, those keys would be included.
> Change the thrift IDL to declare 0x7FFF (Long.MAX_VALUE) as the
> default value for timstamp so that the thrift-generated Key class behaves the
> same way as the Java version.
> [~kturner] pointed me to the getRowRange helper method on the AccumuloProxy
> service. This method helps in some cases, but not the case I mentioned above
> since I have two arbitrary rows. Also, in looking through the code in
> ProxyServer, Keith noticed that the code does not seem to handle timestamps
> correctly. For example, the getRowRange method does not pass a timestamp at
> all (not even the EMPTY value). Also, the internal helper method getProxyKey
> ignores the timestamp on the incoming key.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2111) Allow AccumuloClassLoader to use shell globbing
[ https://issues.apache.org/jira/browse/ACCUMULO-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859254#comment-13859254 ] Christopher Tubbs commented on ACCUMULO-2111: - Personally, I'd rather we just conform to the behavior of java's CLASSPATH environment variable as much as possible. > Allow AccumuloClassLoader to use shell globbing > --- > > Key: ACCUMULO-2111 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2111 > Project: Accumulo > Issue Type: Improvement > Components: start >Affects Versions: 1.4.4, 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > > Right now, the classpath parsing for hte AccumuloClassLoader supports > * non-file URLs > * paths to a jar file > * paths to a directory > * paths with regex matching at the file level > This behavior is undocumented and incompatible with the output of other > ecosystem tools, most importantly the "[hadoop > classpath|http://hadoop.apache.org/docs/r1.0.4/commands_manual.html#classpath]"; > command. that command may use shell globbing (depending on the hadoop > distro). > Proposed solution: > * abstract the matching behavior > * add matching by shell globbing > * add a flag that determines if regex, globbing, or both (regex falling back > to globbing) is used > the flag should default to regex to maintain current out-of-the-box behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2114) default namesapce name should be part of the public api
[ https://issues.apache.org/jira/browse/ACCUMULO-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859253#comment-13859253 ] Christopher Tubbs commented on ACCUMULO-2114: - In what way do you propose users interact with this value? The way it is currently implemented is similar to java classes in the default package. That is, the fully qualified table names for tables in the default namespace have no namespace prefix. Namespaces are not really first class citizens, like tables. So, can you clarify how you think this should change? > default namesapce name should be part of the public api > --- > > Key: ACCUMULO-2114 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2114 > Project: Accumulo > Issue Type: Bug >Reporter: John Vines > Fix For: 1.6.0 > > > The name of the default namespace currently lives in > org.apache.accumulo.client.impl.Namespaces which is not part of the public > api. We should make this variable part of the public API to make it easier > for users to interact with namespaces. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2096) randomwalk AlterTable uses table name instead of ID
[ https://issues.apache.org/jira/browse/ACCUMULO-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859250#comment-13859250 ] Christopher Tubbs commented on ACCUMULO-2096: - Renamed subject, because I don't know what "RW" is at first glance, and this is an unnecessary barrier to addressing the issue. > randomwalk AlterTable uses table name instead of ID > --- > > Key: ACCUMULO-2096 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2096 > Project: Accumulo > Issue Type: Bug > Components: test >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.6.0 > > > RW test uses the table name instead of table ID at > org.apache.accumulo.test.randomwalk.security.AlterTable.visit(AlterTable.java:40) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2000) Monitor should show if TabletServers don't have native maps
[ https://issues.apache.org/jira/browse/ACCUMULO-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-2000: Fix Version/s: 1.7.0 > Monitor should show if TabletServers don't have native maps > --- > > Key: ACCUMULO-2000 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2000 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.4.4, 1.5.0 >Reporter: Sean Busbey >Priority: Minor > Fix For: 1.7.0 > > > It would be nice if the monitor showed when tablet servers are configured to > use native maps but they weren't successfully loaded. > As is, the tablet server's error warning about not loading the maps will > (sometimes) show up in the logs section. a persistent dummy light would be > better because it wouldn't be cleared by clearing the current / recent log > events (which can allow the problem to be masked if an operator forgets about > seeing the event or if there are multiple operators). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2096) randomwalk AlterTable uses table name instead of ID
[ https://issues.apache.org/jira/browse/ACCUMULO-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-2096: Summary: randomwalk AlterTable uses table name instead of ID (was: RW AlterTable uses table name instead of ID) > randomwalk AlterTable uses table name instead of ID > --- > > Key: ACCUMULO-2096 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2096 > Project: Accumulo > Issue Type: Bug > Components: test >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 1.6.0 > > > RW test uses the table name instead of table ID at > org.apache.accumulo.test.randomwalk.security.AlterTable.visit(AlterTable.java:40) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2001) BatchScanner needs setBatchSize
[ https://issues.apache.org/jira/browse/ACCUMULO-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859248#comment-13859248 ] Christopher Tubbs commented on ACCUMULO-2001: - Before moving to a common base class, the naming of this method should be reconsidered... as the "Batch" in "BatchScanner" (requests are batched, according to the hosting tserver) means something completely different than the "Batch" in "setBatchSize" (results are fetched in batches). > BatchScanner needs setBatchSize > --- > > Key: ACCUMULO-2001 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2001 > Project: Accumulo > Issue Type: Improvement >Reporter: Chris McCubbin >Priority: Minor > Fix For: 1.7.0 > > > BatchScanner has very few options for controlling the amount of data > retrieved. Propose moving setBatchSize to ScannerBase to allow for this > configuration option to be applied to BatchScanners as well as scanners. > I also saw ACCUMULO-580 but I think that is a slightly different request, and > also closed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2007) Compaction and flush of root table(t) does not work
[ https://issues.apache.org/jira/browse/ACCUMULO-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859246#comment-13859246 ] Christopher Tubbs commented on ACCUMULO-2007: - Is this really something we want to delay until 1.7? It seems like it might need to be fixed in 1.6.0. > Compaction and flush of root table(t) does not work > --- > > Key: ACCUMULO-2007 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2007 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Keith Turner > Fix For: 1.7.0 > > > Compating and flushing the root table[t] does not work properly. In the case > of flush, I think it will most likely initiate the flush but will not wait > for it. In the case if compaction, I am not sure if it will even initiate > the compaction. > The root table tablet needs to store its flush and compaction count in > zookeeper. The master would need to wait for it to increment in zookeeper. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2013) Cloning tables results in errors from the master
[
https://issues.apache.org/jira/browse/ACCUMULO-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859244#comment-13859244
]
Christopher Tubbs commented on ACCUMULO-2013:
-
Is this fixed now? I made a lot of improvements to the exception handling for
namespaces and table operations in the master in ACCUMULO-1965.
> Cloning tables results in errors from the master
>
>
> Key: ACCUMULO-2013
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2013
> Project: Accumulo
> Issue Type: Bug
> Components: master
>Reporter: John Vines
>Assignee: John Vines
> Fix For: 1.6.0
>
>
> Cloning any normal table, the new table reports an error corresponding to
> it's table ID
> {code}
> Table (o) contains reference to namespace () that doesn't exist
> {code}
> being reported by the master in the monitor.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (ACCUMULO-2012) Cloning the metadata table fails with faulty error
[
https://issues.apache.org/jira/browse/ACCUMULO-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs reassigned ACCUMULO-2012:
---
Assignee: Christopher Tubbs
> Cloning the metadata table fails with faulty error
> --
>
> Key: ACCUMULO-2012
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2012
> Project: Accumulo
> Issue Type: Bug
> Components: client, master
>Reporter: John Vines
>Assignee: Christopher Tubbs
> Fix For: 1.6.0
>
>
> {code}
> Failed to execute Repo, tid=5d7e9a01796a6b64
> java.lang.RuntimeException: table deleted during clone? srcTableId =
> !0
> at
> org.apache.accumulo.server.util.MetadataTableUtil.initializeClone(MetadataTableUtil.java:681)
> at
> org.apache.accumulo.server.util.MetadataTableUtil.cloneTable(MetadataTableUtil.java:783)
> at
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneTable.java:119)
> at
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneTable.java:97)
> at
> org.apache.accumulo.master.tableOps.TraceRepo.call(TraceRepo.java:54)
> at
> org.apache.accumulo.fate.Fate$TransactionRunner.run(Fate.java:67)
> at
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:34)
> at java.lang.Thread.run(Thread.java:701)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2002) Add a convenience method to ScannerBase fetchColumn(IteratorSetting.Column)
[ https://issues.apache.org/jira/browse/ACCUMULO-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-2002: Fix Version/s: 1.7.0 > Add a convenience method to ScannerBase fetchColumn(IteratorSetting.Column) > --- > > Key: ACCUMULO-2002 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2002 > Project: Accumulo > Issue Type: Improvement > Components: client >Affects Versions: 1.5.0 >Reporter: Miguel Pereira >Priority: Minor > Labels: newbie, usability > Fix For: 1.7.0 > > > This is mainly a convenience improvement. In my particular use case I want to > force the client to pass a predefined Column not a String. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-2006) MetadataSplitIT fails
[
https://issues.apache.org/jira/browse/ACCUMULO-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs resolved ACCUMULO-2006.
-
Resolution: Cannot Reproduce
I don't think this is still a valid bug. I've been running this test, along
with the others, without issue, for some time now.
> MetadataSplitIT fails
> -
>
> Key: ACCUMULO-2006
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2006
> Project: Accumulo
> Issue Type: Bug
>Reporter: Eric Newton
>Assignee: Eric Newton
> Fix For: 1.6.0
>
>
> running {{mvn verify}} MetadataSplitIT fails.
> Looking in the master logs, it appears the !METADATA table is not assigned
> after the root table is loaded.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-2023) Default namespace missing from tab completion list in shell
[ https://issues.apache.org/jira/browse/ACCUMULO-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-2023. - Resolution: Won't Fix Assignee: Christopher Tubbs The default namespace is an empty string... this is very confusing in the tab-completion results (because you can't see it), so I intentionally removed it. > Default namespace missing from tab completion list in shell > --- > > Key: ACCUMULO-2023 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2023 > Project: Accumulo > Issue Type: Bug > Components: shell >Reporter: John Vines >Assignee: Christopher Tubbs > Fix For: 1.6.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2040) Document permissions
[
https://issues.apache.org/jira/browse/ACCUMULO-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-2040:
Fix Version/s: 1.6.0
> Document permissions
>
>
> Key: ACCUMULO-2040
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2040
> Project: Accumulo
> Issue Type: Task
> Components: docs
>Reporter: Bill Havanki
>Priority: Minor
> Labels: documentation
> Fix For: 1.6.0
>
>
> Document the various system, table, and namespace permissions, and either
> include the information in the appropriate classes ({{NamespacePermissions}}
> et al.) or provide pointers to the documentation from the Javadoc.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2064) Include Git SHA1 in artifacts
[
https://issues.apache.org/jira/browse/ACCUMULO-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859224#comment-13859224
]
Mike Drob commented on ACCUMULO-2064:
-
When I was doing the 1.4.4 release, I built all artifacts from a {{git
archive}} command. I think this has the benefit of not accidentally including
the .git directory in a release, and is probably good practice anyway.
> Include Git SHA1 in artifacts
> -
>
> Key: ACCUMULO-2064
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2064
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Mike Drob
>Priority: Minor
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> After building a SNAPSHOT version of Accumulo, the Git commit ID it was built
> from is lost in the wind the next time you update you copy of the repo.
> It would be nice to include the SHA1 in the the MANIFEST.MF. I've done this
> before, and I remember it to be rather easy in the end, but I don't remember
> how off the top of my head.
> This would be very useful when running Accumulo's distributed tests during at
> the end of a release cycle to rule out the possibility of running into a bug
> that was already fixed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2043) RemoveEntriesForMissingFiles requires command line password.
[
https://issues.apache.org/jira/browse/ACCUMULO-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-2043:
Fix Version/s: 1.6.0
1.5.1
> RemoveEntriesForMissingFiles requires command line password.
>
>
> Key: ACCUMULO-2043
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2043
> Project: Accumulo
> Issue Type: Bug
>Affects Versions: 1.5.0
>Reporter: Luke Brassard
> Fix For: 1.5.1, 1.6.0
>
>
> {{org.apache.accumulo.server.util.RemoveEntriesForMissingFiles}} requires
> password to be entered on the command line. It should probably prompt.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (ACCUMULO-2077) AddFilesWithMissingEntries doesn't work with !METADATA entries
[ https://issues.apache.org/jira/browse/ACCUMULO-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs reassigned ACCUMULO-2077: --- Assignee: Christopher Tubbs > AddFilesWithMissingEntries doesn't work with !METADATA entries > -- > > Key: ACCUMULO-2077 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2077 > Project: Accumulo > Issue Type: Bug >Reporter: John Vines >Assignee: Christopher Tubbs > Fix For: 1.6.0 > > > After a quick look, the AddFilesWithMissingEntries utility will never write > to the root tablet, which it should for metadata files which need to be > added. This needs to be remedied. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2083) RegExFilter Erroneously Reconstructs RowId Containing Null Character
[ https://issues.apache.org/jira/browse/ACCUMULO-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-2083: Fix Version/s: 1.6.0 1.5.1 > RegExFilter Erroneously Reconstructs RowId Containing Null Character > > > Key: ACCUMULO-2083 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2083 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.5.0 >Reporter: Laura Schanno >Priority: Minor > Fix For: 1.5.1, 1.6.0 > > > I applied a core.iterators.user.RegExFilter iterator to a BatchScanner > iterating over Key,Value pairs where the row id of the Keys are formatted as > "\0\". RegExFilter reconstructed the row id as "", > dropping the sink half. This appears to be due to the usage of the > String(byte bytes[], int offset, int length, Charset charset) constructor to > reset the values of the Matcher objects in the both of the matches() > functions. The String constructor only reconstructs a String up to the "\0" > character. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2054) Concurrent random walk test fails
[
https://issues.apache.org/jira/browse/ACCUMULO-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859210#comment-13859210
]
Christopher Tubbs commented on ACCUMULO-2054:
-
This is marked as fixed. What fixed it?
> Concurrent random walk test fails
> -
>
> Key: ACCUMULO-2054
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2054
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Eric Newton
>Assignee: Eric Newton
>Priority: Minor
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> Random walk testing, the namespace test sometimes fails:
> {noformat}
> 18 16:21:54,810 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node Concurrent.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at
> org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node ct.CreateTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: org.apache.accumulo.core.client.AccumuloSecurityException: Error
> NAMESPACE_DOESNT_EXIST for user root on table nspc_001.ctt_002(?) - Unknown
> security exception
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.doTableOperation(TableOperationsImpl.java:316)
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.doTableOperation(TableOperationsImpl.java:296)
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.create(TableOperationsImpl.java:224)
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.create(TableOperationsImpl.java:193)
> at
> org.apache.accumulo.test.randomwalk.concurrent.CreateTable.visit(CreateTable.java:42)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: ThriftSecurityException(user:root, code:NAMESPACE_DOESNT_EXIST)
> at
> org.apache.accumulo.core.master.thrift.MasterClientService$executeTableOperation_result$executeTableOperation_resultStandardScheme.read(MasterClientService.java:19067)
> at
> org.apache.accumulo.core.master.thrift.MasterClientService$executeTableOperation_result$executeTableOperation_resultStandardScheme.read(MasterClientService.java:19053)
> at
> org.apache.accumulo.core.master.thrift.MasterClientService$executeTableOperation_result.read(MasterClientService.java:18995)
> at
> org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
> at
> org.apache.accumulo.core.master.thrift.MasterClientService$Client.recv_executeTableOperation(MasterClientService.java:582)
> at
> org.apache.accumulo.core.master.thrift.MasterClientService$Client.executeTableOperation(MasterClientService.java:563)
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.executeTableOperation(TableOperationsImpl.java:252)
> at
> org.apache.accumulo.core.client.admin.TableOperationsImpl.doTableOperation(TableOperationsImpl.java:305)
> ... 14 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1797) update release practices to cover multiple Hadoops
[
https://issues.apache.org/jira/browse/ACCUMULO-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859192#comment-13859192
]
Christopher Tubbs commented on ACCUMULO-1797:
-
{quote}the PGP v GPG distinction isn't part of this change, it's the original
text. Can we do that bit in a follow on?{quote}
Sure... and, it's not that important. I had gotten a little confused between
the dashes for the patch and the markdown syntax.
> update release practices to cover multiple Hadoops
> --
>
> Key: ACCUMULO-1797
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1797
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Attachments: ACCUMULO-1797.1-site.patch.txt,
> ACCUMULO-1797.2-site.patch.txt
>
>
> if we're going to label Hadoop platforms as supported, we should ensure the
> release process specifies that tests are run against each of them.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2064) Include Git SHA1 in artifacts
[
https://issues.apache.org/jira/browse/ACCUMULO-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859190#comment-13859190
]
Christopher Tubbs commented on ACCUMULO-2064:
-
[~mdrob] wrote:
{quote}I'm not sure I understand your concern about not being able to reproduce
source releases.{quote}
Two things. First (and, least relevant) is that the SHA1 may not match, if
somebody has mirrored the repository without using git clone (eg. export, then
import), and second (still not that important), building from a source release
tarball (the official release) will not match the released binary from our
build.
I'm inclined to agree with you that the benefits outweigh these concerns.
> Include Git SHA1 in artifacts
> -
>
> Key: ACCUMULO-2064
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2064
> Project: Accumulo
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Mike Drob
>Priority: Minor
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> After building a SNAPSHOT version of Accumulo, the Git commit ID it was built
> from is lost in the wind the next time you update you copy of the repo.
> It would be nice to include the SHA1 in the the MANIFEST.MF. I've done this
> before, and I remember it to be rather easy in the end, but I don't remember
> how off the top of my head.
> This would be very useful when running Accumulo's distributed tests during at
> the end of a release cycle to rule out the possibility of running into a bug
> that was already fixed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-1853) Clean up dependencies for 1.6.0
[
https://issues.apache.org/jira/browse/ACCUMULO-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs resolved ACCUMULO-1853.
-
Resolution: Fixed
I recently took a look myself, and this seemed done.
> Clean up dependencies for 1.6.0
> ---
>
> Key: ACCUMULO-1853
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1853
> Project: Accumulo
> Issue Type: Task
>Reporter: Billie Rinaldi
>Assignee: Billie Rinaldi
> Fix For: 1.6.0
>
> Attachments: ACCUMULO-1853-2.patch, ACCUMULO-1853-3.patch,
> ACCUMULO-1853.patch, BloomFilterIT_jstacks.txt, logs.tgz
>
>
> Output of {{mvn dependency:analyze}}:
> {noformat}
> [INFO] Building Apache Accumulo 1.6.0-SNAPSHOT
> [INFO] Building Trace 1.6.0-SNAPSHOT
> [WARNING] Unused declared dependencies found:
> [WARNING]org.slf4j:slf4j-log4j12:jar:1.7.5:provided
> [INFO] Building Fate 1.6.0-SNAPSHOT
> [INFO] Building Start 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]org.apache.hadoop:hadoop-hdfs:test-jar:tests:2.2.0:test
> [WARNING]org.apache.hadoop:hadoop-common:jar:2.2.0:provided
> [WARNING]org.apache.hadoop:hadoop-hdfs:jar:2.2.0:provided
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.hadoop:hadoop-client:jar:2.2.0:provided
> [WARNING]javax.ws.rs:jsr311-api:jar:1.1.1:test
> [WARNING]org.apache.hadoop:hadoop-minicluster:jar:2.2.0:test
> [WARNING]org.mortbay.jetty:jetty:jar:6.1.26:test
> [WARNING]org.powermock:powermock-api-easymock:jar:1.5:test
> [INFO] Building Core 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]org.apache.hadoop:hadoop-mapreduce-client-core:jar:2.2.0:provided
> [WARNING]commons-configuration:commons-configuration:jar:1.6:provided
> [WARNING]org.powermock:powermock-core:jar:1.5:test
> [WARNING]org.apache.hadoop:hadoop-common:jar:2.2.0:provided
> [WARNING] Unused declared dependencies found:
> [WARNING]commons-httpclient:commons-httpclient:jar:3.1:provided
> [WARNING]org.apache.hadoop:hadoop-client:jar:2.2.0:provided
> [WARNING]org.slf4j:slf4j-log4j12:jar:1.7.5:provided
> [INFO] Building Simple Examples 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]org.apache.hadoop:hadoop-mapreduce-client-core:jar:2.2.0:provided
> [WARNING]org.apache.accumulo:accumulo-trace:jar:1.6.0-SNAPSHOT:compile
> [WARNING]org.apache.accumulo:accumulo-fate:jar:1.6.0-SNAPSHOT:compile
> [WARNING]org.apache.hadoop:hadoop-common:jar:2.2.0:provided
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.zookeeper:zookeeper:jar:3.3.6:compile
> [WARNING]commons-httpclient:commons-httpclient:jar:3.1:provided
> [WARNING]commons-io:commons-io:jar:2.1:provided
> [WARNING]org.apache.hadoop:hadoop-client:jar:2.2.0:provided
> [INFO] Building Server Base 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]com.google.guava:guava:jar:14.0.1:compile
> [WARNING]org.apache.hadoop:hadoop-hdfs:jar:2.2.0:compile
> [WARNING]org.apache.hadoop:hadoop-common:jar:2.2.0:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.code.gson:gson:jar:2.2.2:compile
> [WARNING]javax.servlet:servlet-api:jar:2.5:compile
> [WARNING]org.apache.hadoop:hadoop-client:jar:2.2.0:compile
> [WARNING]org.mortbay.jetty:jetty:jar:6.1.26:compile
> [WARNING]org.slf4j:slf4j-api:jar:1.7.5:test
> [WARNING]org.slf4j:slf4j-log4j12:jar:1.7.5:test
> [INFO] Building GC Server 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]org.apache.zookeeper:zookeeper:jar:3.3.6:compile
> [WARNING]com.beust:jcommander:jar:1.32:compile
> [WARNING]org.apache.thrift:libthrift:jar:0.9.0:compile
> [WARNING]com.google.guava:guava:jar:14.0.1:compile
> [WARNING]org.apache.accumulo:accumulo-fate:jar:1.6.0-SNAPSHOT:compile
> [WARNING]org.apache.accumulo:accumulo-trace:jar:1.6.0-SNAPSHOT:compile
> [WARNING]org.apache.hadoop:hadoop-common:jar:2.2.0:compile
> [WARNING]log4j:log4j:jar:1.2.16:compile
> [WARNING]org.apache.accumulo:accumulo-core:jar:1.6.0-SNAPSHOT:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]org.slf4j:slf4j-api:jar:1.7.5:test
> [WARNING]org.slf4j:slf4j-log4j12:jar:1.7.5:test
> [INFO] Building Master Server 1.6.0-SNAPSHOT
> [WARNING] Used undeclared dependencies found:
> [WARNING]commons-codec:commons-codec:jar:1.7:compile
> [WARNING]org.apache.zookeeper:zookeeper:jar:3.3.6:compile
> [WARNING]com.beust:jcommander:jar:1.32:compile
> [WARNING]org.apache.thrift:libthrift:jar:0.9.0:compile
> [WARNING]com.google.guava:guava:jar:14.0.1:compile
> [WARNING]org.apache.accumulo:accumulo-trace:jar:1.6.0-SNAPSHOT:compile
> [WARNING]org.apache.accumulo:ac
[jira] [Resolved] (ACCUMULO-2088) MasterClient.execute() eats table exceptions
[ https://issues.apache.org/jira/browse/ACCUMULO-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-2088. - Resolution: Fixed Fix Version/s: (was: 1.7.0) 1.6.0 Assignee: Christopher Tubbs Inadvertently fixed in ACCUMULO-1965 > MasterClient.execute() eats table exceptions > > > Key: ACCUMULO-2088 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2088 > Project: Accumulo > Issue Type: Bug >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs > Fix For: 1.6.0 > > > MasterClient.execute() tries to handle all the exceptions, and just wraps > ThriftTableOperationExceptions in an AccumuloException instead of throwing > the correct corresponding TableNotFoundException, etc... > At the very least, this has an impact on setProperty() and removeProperty() > in TableOperations. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2061) Deprecate instance.dfs.uri and instance.dfs.dir
[
https://issues.apache.org/jira/browse/ACCUMULO-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859186#comment-13859186
]
Christopher Tubbs commented on ACCUMULO-2061:
-
It might be a good idea to force resolution of relative paths on upgrade, so we
don't run into problems handling it in inconsistent ways throughout the code
later.
> Deprecate instance.dfs.uri and instance.dfs.dir
> ---
>
> Key: ACCUMULO-2061
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2061
> Project: Accumulo
> Issue Type: Sub-task
> Components: master, tserver
>Reporter: Christopher Tubbs
> Fix For: 1.6.0
>
>
> {{instance.dfs.uri}} and {{instance.dfs.dir}} are no longer needed with the
> {{instance.volumes}} property.
> Together, these two fields are needed for upgrades from relative paths, but
> full URIs for volumes should be specified in the {{instance.volumes}} set.
> Instead of appending {{instance.dfs.dir}} to every volume, which is a bit
> confusing, they should be specified explicitly in the {{instance.volumes}}.
> Example:
> {code}
>
> instance.volumes
> hdfs://nn1/accumulo
>
> {code}
> should be equivalent to
> {code}
>
> instance.dfs.uri
> hdfs://nn1
>
>
> instance.dfs.dir
> /accumulo
>
> {code}
> This change simplifies the semantics of configuring volumes for Accumulo to
> use for storage, and is a bit more obvious that we're logically configuring
> filesystem volumes, not "namenode URIs".
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1976) Need to upgrade to new namespaces
[
https://issues.apache.org/jira/browse/ACCUMULO-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859176#comment-13859176
]
Christopher Tubbs commented on ACCUMULO-1976:
-
I believe I fixed this already. Can anybody confirm it's still an issue?
> Need to upgrade to new namespaces
> -
>
> Key: ACCUMULO-1976
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1976
> Project: Accumulo
> Issue Type: Bug
> Components: master, tserver
>Reporter: John Vines
>Assignee: Christopher Tubbs
>Priority: Blocker
> Fix For: 1.6.0
>
>
> Attempting to start a 1.6.0 on top of 1.5.0 yields-
> {code}2013-12-06 17:47:57,228 [master.Master] FATAL: Error performing upgrade
> java.lang.IllegalArgumentException: Improper table name format
> at
> org.apache.accumulo.core.client.impl.Tables.qualify(Tables.java:188)
> at
> org.apache.accumulo.core.client.impl.Tables.qualified(Tables.java:175)
> at org.apache.accumulo.core.client.impl.Tables.getMap(Tables.java:81)
> at
> org.apache.accumulo.core.client.impl.Tables.getIdToNameMap(Tables.java:111)
> at
> org.apache.accumulo.core.client.impl.Tables.getTableName(Tables.java:100)
> at
> org.apache.accumulo.server.security.AuditedSecurityOperation.getTableName(AuditedSecurityOperation.java:80)
> at
> org.apache.accumulo.server.security.AuditedSecurityOperation.grantTablePermission(AuditedSecurityOperation.java:379)
> at org.apache.accumulo.master.Master.upgradeZookeeper(Master.java:322)
> at org.apache.accumulo.master.Master.setMasterState(Master.java:267)
> at org.apache.accumulo.master.Master.getMasterLock(Master.java:1849)
> at org.apache.accumulo.master.Master.run(Master.java:1678)
> at org.apache.accumulo.master.Master.main(Master.java:1865)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:701)
> {code}
> And then things just die.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1976) Need to upgrade to new namespaces
[
https://issues.apache.org/jira/browse/ACCUMULO-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859177#comment-13859177
]
Christopher Tubbs commented on ACCUMULO-1976:
-
Or, at least, describe their test procedure in more detail so I can reproduce?
> Need to upgrade to new namespaces
> -
>
> Key: ACCUMULO-1976
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1976
> Project: Accumulo
> Issue Type: Bug
> Components: master, tserver
>Reporter: John Vines
>Assignee: Christopher Tubbs
>Priority: Blocker
> Fix For: 1.6.0
>
>
> Attempting to start a 1.6.0 on top of 1.5.0 yields-
> {code}2013-12-06 17:47:57,228 [master.Master] FATAL: Error performing upgrade
> java.lang.IllegalArgumentException: Improper table name format
> at
> org.apache.accumulo.core.client.impl.Tables.qualify(Tables.java:188)
> at
> org.apache.accumulo.core.client.impl.Tables.qualified(Tables.java:175)
> at org.apache.accumulo.core.client.impl.Tables.getMap(Tables.java:81)
> at
> org.apache.accumulo.core.client.impl.Tables.getIdToNameMap(Tables.java:111)
> at
> org.apache.accumulo.core.client.impl.Tables.getTableName(Tables.java:100)
> at
> org.apache.accumulo.server.security.AuditedSecurityOperation.getTableName(AuditedSecurityOperation.java:80)
> at
> org.apache.accumulo.server.security.AuditedSecurityOperation.grantTablePermission(AuditedSecurityOperation.java:379)
> at org.apache.accumulo.master.Master.upgradeZookeeper(Master.java:322)
> at org.apache.accumulo.master.Master.setMasterState(Master.java:267)
> at org.apache.accumulo.master.Master.getMasterLock(Master.java:1849)
> at org.apache.accumulo.master.Master.run(Master.java:1678)
> at org.apache.accumulo.master.Master.main(Master.java:1865)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:701)
> {code}
> And then things just die.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2100) instamo-archetype could use a little clean up
[ https://issues.apache.org/jira/browse/ACCUMULO-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859175#comment-13859175 ] Christopher Tubbs commented on ACCUMULO-2100: - Makes sense. > instamo-archetype could use a little clean up > - > > Key: ACCUMULO-2100 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2100 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > Some of the things I noticed > - mvn test fails, because it took longer than 30 secs to startup the MAC on > my linux box. > - README needs to be updated, usage is incorrect > - pom.xml doesn't hook exec:exec into any lifecycle so you have to call mvn > compile exec:exec -Pwhatever > - Could abstract out a MiniAccumuloClusterWrapper to handle the temp > directory clean up and make the usage across the ShellExample, > MapReduceExample and ExampleAccumuloUnitTest consistent. Would also make it > easier to implement ACCUMULO-2097 and ACCUMULO-2098 > BTW, I am running this against the origin/1.5 branch, targeting an archetype > that is compatible with Accumulo 1.5.0 > Patch coming for review -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1088) master not balancing because balance information is out-of-date
[ https://issues.apache.org/jira/browse/ACCUMULO-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859174#comment-13859174 ] Christopher Tubbs commented on ACCUMULO-1088: - The issue was fixed in ACCUMULO-2112. > master not balancing because balance information is out-of-date > --- > > Key: ACCUMULO-1088 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1088 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.2 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.5.0 > > > During tests with agitation, the test cluster would become unbalanced because > the master did not realize a dead server was restarted. All servers would be > up, but the master would think that a dead server was still out there. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2113) Verify that The Hammer approach to resource leak is a viable short term fix
[ https://issues.apache.org/jira/browse/ACCUMULO-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859149#comment-13859149 ] Jared Winick commented on ACCUMULO-2113: Per conversation on chat, it appears that the proposed code linked in the description is not fully functional on its own and additional code is needed to shutdown the resources internal to the ThriftTransportPool and ZooSession. For the ThriftTransportPool, it seems like there is a static close() method that could be used, but it will not block until the cleanup has happened as it runs in the Closer thread. For ZooSession, it appears you would need to reach in via reflection and iterate over the _sessions_ member to get references to the ZooKeeper objects to call close on them. As we found out in 1858, calling close() on a ZooKeeper is not blocking either (see https://issues.apache.org/jira/browse/ZOOKEEPER-1816). The issue with non-blocking close() methods invoked during the undeployment of a web application is that there can be a race condition between the threads doing the asynchronous cleanup and the application server unloading the classes. A potential workaround is to have the proposed ClientThreads.shutdownNow() method sleep for a short period of time after closing internal resources and before returning. See the comment at https://github.com/jaredwinick/accumulo-1858-test/blob/master/src/main/java/com/koverse/ApplicationServletContextListener.java for more detail. > Verify that The Hammer approach to resource leak is a viable short term fix > --- > > Key: ACCUMULO-2113 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2113 > Project: Accumulo > Issue Type: Task >Affects Versions: 1.4.5, 1.5.1, 1.6.0 >Reporter: Sean Busbey >Assignee: Jared Winick >Priority: Blocker > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > ACCUMULO-1858 contains a link to a test harness for verifying that we aren't > leaking resources in e.g. Tomcat. > We need someone to take "The Hammer" approach [proposed by > Keith|http://mail-archives.apache.org/mod_mbox/accumulo-dev/201312.mbox/%3CCAGUtCHrThjFW-u%2BJK%2BZYALB-qut2VNd5AH1Sb8o7UcQFUXM4xA%40mail.gmail.com%3E] > and verify that it successfully stops the leak. > Afterwords, results should be linked to on the mailing list so we can come to > consensus on how to handle the API change for releases. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2111) Allow AccumuloClassLoader to use shell globbing
[ https://issues.apache.org/jira/browse/ACCUMULO-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859145#comment-13859145 ] Josh Elser commented on ACCUMULO-2111: -- That's fine by me. I've had it in the back of my mind to come up with a good way to generate some more "visually consumable" configuration documentation from our Property class. But that's neither here nor there. > Allow AccumuloClassLoader to use shell globbing > --- > > Key: ACCUMULO-2111 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2111 > Project: Accumulo > Issue Type: Improvement > Components: start >Affects Versions: 1.4.4, 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > > Right now, the classpath parsing for hte AccumuloClassLoader supports > * non-file URLs > * paths to a jar file > * paths to a directory > * paths with regex matching at the file level > This behavior is undocumented and incompatible with the output of other > ecosystem tools, most importantly the "[hadoop > classpath|http://hadoop.apache.org/docs/r1.0.4/commands_manual.html#classpath]"; > command. that command may use shell globbing (depending on the hadoop > distro). > Proposed solution: > * abstract the matching behavior > * add matching by shell globbing > * add a flag that determines if regex, globbing, or both (regex falling back > to globbing) is used > the flag should default to regex to maintain current out-of-the-box behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2111) Allow AccumuloClassLoader to use shell globbing
[ https://issues.apache.org/jira/browse/ACCUMULO-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859142#comment-13859142 ] Sean Busbey commented on ACCUMULO-2111: --- This is documented in the configuration property descriptions, just not in the user manual. Unless someone objects, I'm going to consider that documented enough. > Allow AccumuloClassLoader to use shell globbing > --- > > Key: ACCUMULO-2111 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2111 > Project: Accumulo > Issue Type: Improvement > Components: start >Affects Versions: 1.4.4, 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey > > Right now, the classpath parsing for hte AccumuloClassLoader supports > * non-file URLs > * paths to a jar file > * paths to a directory > * paths with regex matching at the file level > This behavior is undocumented and incompatible with the output of other > ecosystem tools, most importantly the "[hadoop > classpath|http://hadoop.apache.org/docs/r1.0.4/commands_manual.html#classpath]"; > command. that command may use shell globbing (depending on the hadoop > distro). > Proposed solution: > * abstract the matching behavior > * add matching by shell globbing > * add a flag that determines if regex, globbing, or both (regex falling back > to globbing) is used > the flag should default to regex to maintain current out-of-the-box behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2100) instamo-archetype could use a little clean up
[ https://issues.apache.org/jira/browse/ACCUMULO-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859133#comment-13859133 ] Josh Elser commented on ACCUMULO-2100: -- Because I don't think it *should* match the Accumulo versioning. Play along with me for a little bit. What we (at least, I) wanted to see from the Archetype is a simple way to spin up Accumulo with some examples of code running against that version. Assuming that we get (and stay) in a place where we match adhere to semantic versioning, we really want archetypes against the major versions of Accumulo (right now 1.4 and 1.5, soon 1.6). You'll also notice that the artifact was renamed to accumulo-instamo-archetype-1.4. So, the accumulo-instamo-archetype-1.4 will pull down and provide you the latest 1.4 variant of Accumulo. The versioning of the archetype therefore also doesn't need to be arbitrarily tied to Accumulo versions, nor does the user need to be cognizant of the versioning of each artifact. Consider, how do handle updates to the example of the archetype that don't change Accumulo version dependencies? We would have to introduce some new versioning on top of the Accumulo version, and users would have to go and check to find out that a new version was released. I think this approach will: # Be easier to use for users as they don't need to track Archetype versions # Help keep us honest with upstream Accumulo versioning (eat our own dogfood) Mike and I had talked about this over email before he made these tickets, so I apologize for not having that here. > instamo-archetype could use a little clean up > - > > Key: ACCUMULO-2100 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2100 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > Some of the things I noticed > - mvn test fails, because it took longer than 30 secs to startup the MAC on > my linux box. > - README needs to be updated, usage is incorrect > - pom.xml doesn't hook exec:exec into any lifecycle so you have to call mvn > compile exec:exec -Pwhatever > - Could abstract out a MiniAccumuloClusterWrapper to handle the temp > directory clean up and make the usage across the ShellExample, > MapReduceExample and ExampleAccumuloUnitTest consistent. Would also make it > easier to implement ACCUMULO-2097 and ACCUMULO-2098 > BTW, I am running this against the origin/1.5 branch, targeting an archetype > that is compatible with Accumulo 1.5.0 > Patch coming for review -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859132#comment-13859132 ] Michael Wall commented on ACCUMULO-2112: This issue showed up in the master logs as "ERROR: unable to get tablet server status". The tservers appeared to lose connection for a brief time, less than 30 seconds, but then start communicating again. The server would then show up by IP in the list of Unresponsive servers and by hostname in the Tablet Servers when looking at the Tablet Server page of the monitor. I can verify applying this one line fix to the 1.4.4 tag removes the server from the list of unresponsive servers and balancing begins again when there are no unresponsive servers. The "unable to get server status" should still show up in the master logs. Maybe it is actually meaningful. > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859129#comment-13859129
]
Sean Busbey commented on ACCUMULO-2105:
---
[~ecn] please bring up your issues in the mailing list thread on resource
cleanup.
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2100) instamo-archetype could use a little clean up
[ https://issues.apache.org/jira/browse/ACCUMULO-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859128#comment-13859128 ] Christopher Tubbs commented on ACCUMULO-2100: - Why was the artifact re-versioned to 2.0.0? This could be very confusing if it doesn't match Accumulo's versioning (especially, the major version). > instamo-archetype could use a little clean up > - > > Key: ACCUMULO-2100 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2100 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > Some of the things I noticed > - mvn test fails, because it took longer than 30 secs to startup the MAC on > my linux box. > - README needs to be updated, usage is incorrect > - pom.xml doesn't hook exec:exec into any lifecycle so you have to call mvn > compile exec:exec -Pwhatever > - Could abstract out a MiniAccumuloClusterWrapper to handle the temp > directory clean up and make the usage across the ShellExample, > MapReduceExample and ExampleAccumuloUnitTest consistent. Would also make it > easier to implement ACCUMULO-2097 and ACCUMULO-2098 > BTW, I am running this against the origin/1.5 branch, targeting an archetype > that is compatible with Accumulo 1.5.0 > Patch coming for review -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859120#comment-13859120 ] Josh Elser commented on ACCUMULO-2115: -- bq. I have copied jars out to lib/ext on numerous occasions without seeing this issue. It could be a race condition or something added in 1.4.4 Likewise -- I know I've seen my share of weirdness with the 1.4 reloading of classes, but this one doesn't ring a bell to me. If I use 1.4, it's mostly been 1.4.5-SNAPSHOT, but I can't say I've run into things recently. Either way, more details would be great if you have them, [~ivan.bella]. > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859118#comment-13859118 ] Dave Marion commented on ACCUMULO-2115: --- The class loaders between 1.4 and 1.5 were about a 90% rewrite. If this issue affects 1.5, it's likely a different ticket/solution. I have copied jars out to lib/ext on numerous occasions without seeing this issue. It could be a race condition or something added in 1.4.4. I would suggest that the submitter raise the priority of this issue if it keeps occurring. > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1923) Ensure ZK instances closed correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859115#comment-13859115
]
Josh Elser commented on ACCUMULO-1923:
--
Eric's changes in 379881e have resolved the MapReduceIT failures for me.
> Ensure ZK instances closed correctly
>
>
> Key: ACCUMULO-1923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1923
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Environment: development single node, hadoop 2.2,
>Reporter: Eric Newton
>Assignee: Bill Havanki
>Priority: Critical
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> Was: "warning at the end of a MapReduce job"
> Ensure that ZK instances are closed where opened across the Accumulo
> codebase. This is an expansion of the original ticket scope, whose
> description is below.
> Original Description:
> While running the randomwalk tests I saw this at the end of a map/reduce job:
> {noformat}
> 22 16:56:30,583 [client.ZooKeeperInstance] WARN : ZooKeeperInstance being
> cleaned up without being closed. Please remember to call close() before
> dereferencing to clean up threads.
> {noformat}
> This came just after the warning:
> {noformat}
> 22 16:56:31,742 [sequential.MapRedVerify] DEBUG: Dropping table:
> sequential_hostname_1385157013877_MR
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1923) Ensure ZK instances closed correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated ACCUMULO-1923:
-
Priority: Minor (was: Critical)
> Ensure ZK instances closed correctly
>
>
> Key: ACCUMULO-1923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1923
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Environment: development single node, hadoop 2.2,
>Reporter: Eric Newton
>Assignee: Bill Havanki
>Priority: Minor
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> Was: "warning at the end of a MapReduce job"
> Ensure that ZK instances are closed where opened across the Accumulo
> codebase. This is an expansion of the original ticket scope, whose
> description is below.
> Original Description:
> While running the randomwalk tests I saw this at the end of a map/reduce job:
> {noformat}
> 22 16:56:30,583 [client.ZooKeeperInstance] WARN : ZooKeeperInstance being
> cleaned up without being closed. Please remember to call close() before
> dereferencing to clean up threads.
> {noformat}
> This came just after the warning:
> {noformat}
> 22 16:56:31,742 [sequential.MapRedVerify] DEBUG: Dropping table:
> sequential_hostname_1385157013877_MR
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859111#comment-13859111
]
Josh Elser commented on ACCUMULO-2105:
--
Final implementation aside, I was only concerned about tests that were left
broken due to the changes that were applied. I suppose I can run the
MapReduceIT myself with your changes.
Thanks for looking at this, too.
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859108#comment-13859108
]
Eric Newton commented on ACCUMULO-2105:
---
ACCUMULO-1923 is still open, and will probably not get closed. This experience
is making me lean away from making {{Instance}} a {{Closable}} or even having
the {{close}} method.
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859101#comment-13859101
]
Josh Elser commented on ACCUMULO-2105:
--
[~ecn], do these changes also satisfy the comments on ACCUMULO-1923, notably
MapReduceIT?
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton resolved ACCUMULO-2105.
---
Resolution: Fixed
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859093#comment-13859093
]
ASF subversion and git services commented on ACCUMULO-2105:
---
Commit 379881e69bd7e93f11cfa13b415afe14be8634f6 in branch
refs/heads/1.6.0-SNAPSHOT from [~ecn]
[ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=379881e ]
ACCUMULO-2105 cannot close instance
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859095#comment-13859095
]
ASF subversion and git services commented on ACCUMULO-2105:
---
Commit 379881e69bd7e93f11cfa13b415afe14be8634f6 in branch refs/heads/master
from [~ecn]
[ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=379881e ]
ACCUMULO-2105 cannot close instance
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-2115: - Affects Version/s: (was: 1.5.0) > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859085#comment-13859085 ] Josh Elser commented on ACCUMULO-2115: -- Ah, ok. I'll remove the 1.5.0 affects for now, and leave a caveat here that it would be good to verify that this also doesn't affect 1.5.0 (and 1.6.0 potentially) > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859080#comment-13859080 ] John Vines commented on ACCUMULO-2115: -- There were classloader behavior changes between 1.4.4 and 1.5.0. So it may not affect the 1.5.0 and 1.6.0. Specifically, now the classloaders don't get changed, but the classloader gets replaced, so the old threads should have the old classloader bu thte new ones should have the new one. > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4, 1.5.0 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859076#comment-13859076 ] Bill Havanki commented on ACCUMULO-2030: That's fine. I was considering dropping the ref anyway in light of your comment. As long as I am not missing a complaint from the javadoc tool that you are seeing, I'm satisfied. > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859073#comment-13859073 ] Josh Elser commented on ACCUMULO-2115: -- I imagine that this would continue to bite us through all releases, no? I can't imagine commons-vfs having anything magical that would "fix" this kind of issue for us in 1.5.0. Tying a scan back to the Iterator(s) that might be loaded from a jar that was replaced would likely get rather messy. It's probably possible to inspect the Scan "stack" (and table configuration?) to determine if a jar is in use before replacing it in the classloader. Do you have any thoughts about how to implement this? > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4, 1.5.0 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
[ https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-2115: - Affects Version/s: 1.5.0 > class loader issues when replacing jar that is actively being used > -- > > Key: ACCUMULO-2115 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.4.4, 1.5.0 >Reporter: Ivan Bella >Priority: Minor > Labels: class_loader > > When replacing a jar in the lib/ext directory while active iterators are > using the previous jar will result is many class loader issues. New > iterators started up may also show class loader issues. This will probably > persist until the previously active iterators complete and release the > previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ACCUMULO-2115) class loader issues when replacing jar that is actively being used
Ivan Bella created ACCUMULO-2115: Summary: class loader issues when replacing jar that is actively being used Key: ACCUMULO-2115 URL: https://issues.apache.org/jira/browse/ACCUMULO-2115 Project: Accumulo Issue Type: Bug Components: tserver Affects Versions: 1.4.4 Reporter: Ivan Bella Priority: Minor When replacing a jar in the lib/ext directory while active iterators are using the previous jar will result is many class loader issues. New iterators started up may also show class loader issues. This will probably persist until the previously active iterators complete and release the previous ClassLoader instance, but that is merely a guess. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ACCUMULO-2114) default namesapce name should be part of the public api
John Vines created ACCUMULO-2114: Summary: default namesapce name should be part of the public api Key: ACCUMULO-2114 URL: https://issues.apache.org/jira/browse/ACCUMULO-2114 Project: Accumulo Issue Type: Bug Reporter: John Vines Fix For: 1.6.0 The name of the default namespace currently lives in org.apache.accumulo.client.impl.Namespaces which is not part of the public api. We should make this variable part of the public API to make it easier for users to interact with namespaces. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (ACCUMULO-2105) [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
[
https://issues.apache.org/jira/browse/ACCUMULO-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton reassigned ACCUMULO-2105:
-
Assignee: Eric Newton
> [RW] Multitable.CopyTable failed from using a closed ZooKeeperInstance
> --
>
> Key: ACCUMULO-2105
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2105
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
>Assignee: Eric Newton
> Labels: randomwalk
> Fix For: 1.6.0
>
>
> {noformat}
> 27 02:03:25,324 [randomwalk.Framework] ERROR: Error during random walk
> java.lang.Exception: Error running node MultiTable.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node mt.CopyTable
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.io.IOException: java.lang.RuntimeException: ZooKeeperInstance
> has been closed.
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:596)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:491)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:508)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:392)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
> at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTool.run(CopyTool.java:79)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.accumulo.test.randomwalk.multitable.CopyTable.visit(CopyTable.java:59)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> Caused by: java.lang.RuntimeException: ZooKeeperInstance has been closed.
> at
> org.apache.accumulo.core.client.ZooKeeperInstance.getInstanceID(ZooKeeperInstance.java:162)
> at
> org.apache.accumulo.core.security.Credentials.toThrift(Credentials.java:62)
> at
> org.apache.accumulo.core.client.impl.ThriftScanner.getBatchFromServer(ThriftScanner.java:99)
> at
> org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablet(MetadataLocationObtainer.java:100)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.lookupTabletLocation(TabletLocatorImpl.java:462)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(TabletLocatorImpl.java:619)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:278)
> at
> org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(TabletLocatorImpl.java:353)
> at
> org.apache.accumulo.core.client.mapreduce.AbstractInputFormat.getSplits(AbstractInputFormat.java:582)
> ... 23 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2110) [RW] Error in Bulk.Verify
[
https://issues.apache.org/jira/browse/ACCUMULO-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859039#comment-13859039
]
Josh Elser commented on ACCUMULO-2110:
--
Ok, that's good to know.
> [RW] Error in Bulk.Verify
> -
>
> Key: ACCUMULO-2110
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2110
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
> Fix For: 1.6.0
>
>
> Saw this across three different RW clients. Obviously the key differs each
> time.
> {noformat}
> java.lang.Exception: Error running node Bulk.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at
> org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node bulk.Verify
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.lang.Exception: Bad key at r08930 cf:000 [] 1388209514232
> false 1
> at
> org.apache.accumulo.test.randomwalk.bulk.Verify.visit(Verify.java:65)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> {noformat}
> Some relevant logs from the RW client, but there's nothing in the server log
> that I've seen.
> {noformat}
> 27 21:18:34,660 [bulk.BulkPlusOne] DEBUG: preparing bulk files with start
> rows [r0, r00483, r08930, r0a413, r0a603, r0b20e, r10a31, r1481e, r15e3d,
> r1853e] last row r1869f marker 379
> ...
> 27 21:21:03,710 [bulk.BulkPlusOne] DEBUG: Finished bulk import, start rows
> [r0, r00483, r08930, r0a413, r0a603, r0b20e, r10a31, r1481e, r15e3d,
> r1853e] last row r1869f marker 379
> 27 21:21:03,710 [bulk.BulkPlusOne] INFO : Incrementing
> ...
> 27 21:48:36,260 [impl.ThriftTransportPool] INFO : Thread "bulkImportPool 3"
> no longer stuck on IO to master: (0) sawError = false
> 27 21:48:36,347 [bulk.Compact] INFO : Compaction (r0349f -> r08a2e] finished
> 27 21:48:44,229 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r0077a;r004a1,tserver1:9997,1432840570f049e)
> 27 21:48:46,145 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r007d5;r0077a,tserver1:9997,1432840570f049e)
> 27 21:48:48,738 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r00f3b;r00e54,tserver3:9997,34328404fc00428)
> 27 21:48:50,331 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r014f1;r00f3b,tserver3:9997,34328404fc00428)
> 27 21:49:00,030 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r017a3;r014f1,tserver1:9997,1432840570f049e)
> 27 21:49:07,122 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r02f24;r02824,tserver4:9997,1432840570f045b)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859031#comment-13859031 ] Christopher Tubbs commented on ACCUMULO-2030: - [~bhavanki] Sorry; didn't see your comment before pushing, and it was pretty quick to just do it. As for the ambiguity... there is an ambiguity between the overloaded constructors, one that takes Collection, and one that takes List. I'm not sure it matters much, though, because I don't know that the javadoc benefited from the reference, because the method and the referenced constructor have no more special relationship between them than any other constructor. > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2110) [RW] Error in Bulk.Verify
[
https://issues.apache.org/jira/browse/ACCUMULO-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859030#comment-13859030
]
Eric Newton commented on ACCUMULO-2110:
---
[~elserj], it's probably a bug in accumulo. This test has been stable.
> [RW] Error in Bulk.Verify
> -
>
> Key: ACCUMULO-2110
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2110
> Project: Accumulo
> Issue Type: Bug
> Components: test
>Reporter: Josh Elser
> Fix For: 1.6.0
>
>
> Saw this across three different RW clients. Obviously the key differs each
> time.
> {noformat}
> java.lang.Exception: Error running node Bulk.xml
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at
> org.apache.accumulo.test.randomwalk.Framework.run(Framework.java:65)
> at
> org.apache.accumulo.test.randomwalk.Framework.main(Framework.java:125)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.accumulo.start.Main$1.run(Main.java:137)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Error running node bulk.Verify
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:285)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 8 more
> Caused by: java.lang.Exception: Bad key at r08930 cf:000 [] 1388209514232
> false 1
> at
> org.apache.accumulo.test.randomwalk.bulk.Verify.visit(Verify.java:65)
> at org.apache.accumulo.test.randomwalk.Module.visit(Module.java:254)
> ... 9 more
> {noformat}
> Some relevant logs from the RW client, but there's nothing in the server log
> that I've seen.
> {noformat}
> 27 21:18:34,660 [bulk.BulkPlusOne] DEBUG: preparing bulk files with start
> rows [r0, r00483, r08930, r0a413, r0a603, r0b20e, r10a31, r1481e, r15e3d,
> r1853e] last row r1869f marker 379
> ...
> 27 21:21:03,710 [bulk.BulkPlusOne] DEBUG: Finished bulk import, start rows
> [r0, r00483, r08930, r0a413, r0a603, r0b20e, r10a31, r1481e, r15e3d,
> r1853e] last row r1869f marker 379
> 27 21:21:03,710 [bulk.BulkPlusOne] INFO : Incrementing
> ...
> 27 21:48:36,260 [impl.ThriftTransportPool] INFO : Thread "bulkImportPool 3"
> no longer stuck on IO to master: (0) sawError = false
> 27 21:48:36,347 [bulk.Compact] INFO : Compaction (r0349f -> r08a2e] finished
> 27 21:48:44,229 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r0077a;r004a1,tserver1:9997,1432840570f049e)
> 27 21:48:46,145 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r007d5;r0077a,tserver1:9997,1432840570f049e)
> 27 21:48:48,738 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r00f3b;r00e54,tserver3:9997,34328404fc00428)
> 27 21:48:50,331 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r014f1;r00f3b,tserver3:9997,34328404fc00428)
> 27 21:49:00,030 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r017a3;r014f1,tserver1:9997,1432840570f049e)
> 27 21:49:07,122 [impl.ThriftScanner] DEBUG: Scan failed, not serving tablet
> (lw;r02f24;r02824,tserver4:9997,1432840570f045b)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1797) update release practices to cover multiple Hadoops
[ https://issues.apache.org/jira/browse/ACCUMULO-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859021#comment-13859021 ] Sean Busbey commented on ACCUMULO-1797: --- the PGP v GPG distinction isn't part of this change, it's the original text. Can we do that bit in a follow on? > update release practices to cover multiple Hadoops > -- > > Key: ACCUMULO-1797 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1797 > Project: Accumulo > Issue Type: Sub-task >Reporter: Sean Busbey >Assignee: Sean Busbey > Attachments: ACCUMULO-1797.1-site.patch.txt, > ACCUMULO-1797.2-site.patch.txt > > > if we're going to label Hadoop platforms as supported, we should ensure the > release process specifies that tests are run against each of them. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1797) update release practices to cover multiple Hadoops
[
https://issues.apache.org/jira/browse/ACCUMULO-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859016#comment-13859016
]
Christopher Tubbs commented on ACCUMULO-1797:
-
{{`mvn test`}} doesn't work in some versions, because the test scope in some
modules depend on another module being packaged. You should change {{`mvn
test`}} to {{`mvn package`}}. Also, "PGP" should be changed to "GPG", to reduce
confusion, and the diff would be easier to examine if long lines were wrapped
at something reasonable.
> update release practices to cover multiple Hadoops
> --
>
> Key: ACCUMULO-1797
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1797
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Attachments: ACCUMULO-1797.1-site.patch.txt,
> ACCUMULO-1797.2-site.patch.txt
>
>
> if we're going to label Hadoop platforms as supported, we should ensure the
> release process specifies that tests are run against each of them.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton resolved ACCUMULO-2112. --- Resolution: Fixed > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859003#comment-13859003 ] ASF subversion and git services commented on ACCUMULO-2112: --- Commit f56ae10b3e72e6d03fa6324afcd23619ea94b7b9 in branch refs/heads/1.6.0-SNAPSHOT from [~ecn] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f56ae10 ] ACCUMULO-2112 clear the bad server list of any server that is communicating > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859002#comment-13859002 ] ASF subversion and git services commented on ACCUMULO-2112: --- Commit f56ae10b3e72e6d03fa6324afcd23619ea94b7b9 in branch refs/heads/1.5.1-SNAPSHOT from [~ecn] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f56ae10 ] ACCUMULO-2112 clear the bad server list of any server that is communicating > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (ACCUMULO-1988) Example map reduce not running in functional test
[
https://issues.apache.org/jira/browse/ACCUMULO-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Havanki reassigned ACCUMULO-1988:
--
Assignee: Bill Havanki
> Example map reduce not running in functional test
> -
>
> Key: ACCUMULO-1988
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1988
> Project: Accumulo
> Issue Type: Sub-task
> Components: test
>Reporter: Keith Turner
>Assignee: Bill Havanki
> Fix For: 1.5.1
>
>
> While merging fixes for ACCUMULO-1878 from 1.4 to 1.5 I noticed that example
> map reduce jobs were failing and the return code was not checked. Below is
> an example of one of the failing test.
> {noformat}
> $ ./test/system/auto/run.py -t example -v 10
>.
>.
>.
> DEBUG:test.auto:node1:
> /home/kturner/workspace/accumulo-1.5.1-SNAPSHOT/bin/tool.sh
> /home/kturner/workspace/accumulo-1.5.1-SNAPSHOT/lib/accumulo-examples-simple.jar
> org.apache.accumulo.examples.simple.mapreduce.RowHash -i node1-37680 -z
> localhost:2181 -u root -p secret -t sorted --column : sortedHashed
> DEBUG:test.auto:Output from command: Usage:
> org.apache.accumulo.examples.simple.mapreduce.RowHash [options]
> Options:
> -auths, --auths
>the authorizations to use when reading or writing
>Default:
> * --column
>
> --debug
>turn on TRACE-level log messages
>Default: false
> -h, -?, --help, -help
>
>Default: false
> -i, --instance
>The name of the accumulo instance
> -z, --keepers
>Comma separated list of zookeeper hosts (host:port,host:port)
>Default: localhost:2181
> -fake, --mock
>Use a mock Instance
>Default: false
> --password
>Enter the connection password
> --site-file
>Read the given accumulo site file to find the accumulo instance
> * -t, --table
>table to use
> -tc, --tokenClass
>Token class
>Default: org.apache.accumulo.core.client.security.tokens.PasswordToken
> --trace
>turn on distributed tracing
>Default: false
> -u, --user
>Connection user
>Default: kturner
> -l
>login properties in the format key=value. Reuse -l for each property
>(prompt for properties if this option is missing
>Syntax: -lkey=value
>Default: {}
> -p
>Connection password
> INFO:test.auto:Error output from command: Was passed main parameter
> 'sortedHashed' but no main parameter was defined
> DEBUG:test.auto:Exit code: 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859001#comment-13859001 ] ASF subversion and git services commented on ACCUMULO-2112: --- Commit f56ae10b3e72e6d03fa6324afcd23619ea94b7b9 in branch refs/heads/1.4.5-SNAPSHOT from [~ecn] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f56ae10 ] ACCUMULO-2112 clear the bad server list of any server that is communicating > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2112) master does not balance after intermittent communication failure
[ https://issues.apache.org/jira/browse/ACCUMULO-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859004#comment-13859004 ] ASF subversion and git services commented on ACCUMULO-2112: --- Commit f56ae10b3e72e6d03fa6324afcd23619ea94b7b9 in branch refs/heads/master from [~ecn] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f56ae10 ] ACCUMULO-2112 clear the bad server list of any server that is communicating > master does not balance after intermittent communication failure > > > Key: ACCUMULO-2112 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 > Project: Accumulo > Issue Type: Bug > Components: master >Affects Versions: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1 >Reporter: Eric Newton >Assignee: Eric Newton > Fix For: 1.4.5, 1.5.1, 1.6.0 > > > The master had a momentary connection timeout error collecting stats from a > single tablet server. Because the connection was re-established on the next > attempt, the master did not remove it from the bad servers list. Because the > bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ACCUMULO-2113) Verify that The Hammer approach to resource leak is a viable short term fix
Sean Busbey created ACCUMULO-2113: - Summary: Verify that The Hammer approach to resource leak is a viable short term fix Key: ACCUMULO-2113 URL: https://issues.apache.org/jira/browse/ACCUMULO-2113 Project: Accumulo Issue Type: Task Affects Versions: 1.4.5, 1.5.1, 1.6.0 Reporter: Sean Busbey Assignee: Jared Winick Priority: Blocker Fix For: 1.4.5, 1.5.1, 1.6.0 ACCUMULO-1858 contains a link to a test harness for verifying that we aren't leaking resources in e.g. Tomcat. We need someone to take "The Hammer" approach [proposed by Keith|http://mail-archives.apache.org/mod_mbox/accumulo-dev/201312.mbox/%3CCAGUtCHrThjFW-u%2BJK%2BZYALB-qut2VNd5AH1Sb8o7UcQFUXM4xA%40mail.gmail.com%3E] and verify that it successfully stops the leak. Afterwords, results should be linked to on the mailing list so we can come to consensus on how to handle the API change for releases. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858991#comment-13858991 ] Josh Elser commented on ACCUMULO-2030: -- (this is what happens when you start typing vim commands in your browser.. sorry!) > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-2030: - Assignee: Bill Havanki (was: Josh Elser) > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned ACCUMULO-2030: Assignee: Josh Elser (was: Bill Havanki) > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Josh Elser >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858982#comment-13858982 ] Bill Havanki commented on ACCUMULO-2030: OK, I guess I'll skip that second patch then. > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ACCUMULO-2112) master does not balance after intermittent communication failure
Eric Newton created ACCUMULO-2112: - Summary: master does not balance after intermittent communication failure Key: ACCUMULO-2112 URL: https://issues.apache.org/jira/browse/ACCUMULO-2112 Project: Accumulo Issue Type: Bug Components: master Affects Versions: 1.5.0, 1.4.4, 1.4.3, 1.4.2, 1.4.1, 1.4.0, 1.5.1 Reporter: Eric Newton Assignee: Eric Newton Fix For: 1.4.5, 1.5.1, 1.6.0 The master had a momentary connection timeout error collecting stats from a single tablet server. Because the connection was re-established on the next attempt, the master did not remove it from the bad servers list. Because the bad server list was not cleared, it did not re-balance. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (ACCUMULO-1966) Clone table has race condition when excluding namespace properties
[ https://issues.apache.org/jira/browse/ACCUMULO-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-1966. - Resolution: Fixed Assignee: Christopher Tubbs I believe I fixed this with a commit against ACCUMULO-1965. The relevant client-side code was removed, and relies on the server-side copy of the source table's config. > Clone table has race condition when excluding namespace properties > -- > > Key: ACCUMULO-1966 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1966 > Project: Accumulo > Issue Type: Sub-task > Components: client, master, tserver >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs > Fix For: 1.6.0 > > > Found on ReviewBoard for ACCUMULO-802: > The clone method excludes properties which are unique to namespaces with a > getUniqueNamespaceProperties() method. > # I'm not sure it should be doing this at all (should a clone have the same > behavior, plus any additional configuration not overridden by the table, when > it appears in the new namespace, or should it only clone the properties that > distinguish it from the namespace it was previously in?) > # It could suffer from race conditions, because it is checking on the client > side. > (Creating this ticket, so I can close the ReviewBoard one). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858962#comment-13858962 ] ASF subversion and git services commented on ACCUMULO-2030: --- Commit 063c88d7e28573888ebb56773071ba344920a1dd in branch refs/heads/1.6.0-SNAPSHOT from [~ctubbsii] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=063c88d ] ACCUMULO-2030 Clean up javadoc Fix ambiguous javadoc reference by removing it Remove incorrect exception declaration Remove unused import warning > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1923) Ensure ZK instances closed correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858928#comment-13858928
]
Josh Elser commented on ACCUMULO-1923:
--
This appears to be an issue across a couple of different places and I don't
want it to get missed
> Ensure ZK instances closed correctly
>
>
> Key: ACCUMULO-1923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1923
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Environment: development single node, hadoop 2.2,
>Reporter: Eric Newton
>Assignee: Bill Havanki
>Priority: Critical
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> Was: "warning at the end of a MapReduce job"
> Ensure that ZK instances are closed where opened across the Accumulo
> codebase. This is an expansion of the original ticket scope, whose
> description is below.
> Original Description:
> While running the randomwalk tests I saw this at the end of a map/reduce job:
> {noformat}
> 22 16:56:30,583 [client.ZooKeeperInstance] WARN : ZooKeeperInstance being
> cleaned up without being closed. Please remember to call close() before
> dereferencing to clean up threads.
> {noformat}
> This came just after the warning:
> {noformat}
> 22 16:56:31,742 [sequential.MapRedVerify] DEBUG: Dropping table:
> sequential_hostname_1385157013877_MR
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1923) Ensure ZK instances closed correctly
[
https://issues.apache.org/jira/browse/ACCUMULO-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated ACCUMULO-1923:
-
Priority: Critical (was: Minor)
> Ensure ZK instances closed correctly
>
>
> Key: ACCUMULO-1923
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1923
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Environment: development single node, hadoop 2.2,
>Reporter: Eric Newton
>Assignee: Bill Havanki
>Priority: Critical
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> Was: "warning at the end of a MapReduce job"
> Ensure that ZK instances are closed where opened across the Accumulo
> codebase. This is an expansion of the original ticket scope, whose
> description is below.
> Original Description:
> While running the randomwalk tests I saw this at the end of a map/reduce job:
> {noformat}
> 22 16:56:30,583 [client.ZooKeeperInstance] WARN : ZooKeeperInstance being
> cleaned up without being closed. Please remember to call close() before
> dereferencing to clean up threads.
> {noformat}
> This came just after the warning:
> {noformat}
> 22 16:56:31,742 [sequential.MapRedVerify] DEBUG: Dropping table:
> sequential_hostname_1385157013877_MR
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2100) instamo-archetype could use a little clean up
[ https://issues.apache.org/jira/browse/ACCUMULO-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858926#comment-13858926 ] Michael Wall commented on ACCUMULO-2100: No worries [~elserj]. I'll look at the branch and see if I had anything different. Thanks man > instamo-archetype could use a little clean up > - > > Key: ACCUMULO-2100 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2100 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > Some of the things I noticed > - mvn test fails, because it took longer than 30 secs to startup the MAC on > my linux box. > - README needs to be updated, usage is incorrect > - pom.xml doesn't hook exec:exec into any lifecycle so you have to call mvn > compile exec:exec -Pwhatever > - Could abstract out a MiniAccumuloClusterWrapper to handle the temp > directory clean up and make the usage across the ShellExample, > MapReduceExample and ExampleAccumuloUnitTest consistent. Would also make it > easier to implement ACCUMULO-2097 and ACCUMULO-2098 > BTW, I am running this against the origin/1.5 branch, targeting an archetype > that is compatible with Accumulo 1.5.0 > Patch coming for review -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (ACCUMULO-2097) Add ability to load when from script when MiniAccumuloCluster starts up
[ https://issues.apache.org/jira/browse/ACCUMULO-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858922#comment-13858922 ] Josh Elser edited comment on ACCUMULO-2097 at 12/30/13 5:01 PM: bq. I'm already working on the CSV/TSV part, even though there is not a JIRA for it yet. Do you want to wait for me to finish that so you can integrate it in, or do you have different plans? /me facepalm I just worked up a bunch of stuff last night too, haha. I was making something standalone and then going to see how/where it makes sense to merge it in. Lemme push my stuff to Github for now. Edit: https://github.com/joshelser/accumulo-csv I got most of the boilerplate stubbed out last night. I was planning on supporting rfile creation or mutation writing. I also planned to implement a rudimentary schema support to show how the non-fixed colfam set for a table can be used and tracked. was (Author: elserj): bq. I'm already working on the CSV/TSV part, even though there is not a JIRA for it yet. Do you want to wait for me to finish that so you can integrate it in, or do you have different plans? /me facepalm I just worked up a bunch of stuff last night too, haha. I was making something standalone and then going to see how/where it makes sense to merge it in. Lemme push my stuff to Github for now. > Add ability to load when from script when MiniAccumuloCluster starts up > --- > > Key: ACCUMULO-2097 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2097 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > It would be helpful to be able load data from a script when the > MiniAccumuloCluster starts up from the instamo-archetype generated project. > I was thinking something like the -f option from the shell which simply runs > commands. My idea here is that it is easy to load that same file on a real > cluster and have the same data used in testing. I have written something > like this in the past that parsed the file and created mutations. > [~elserj] suggested loading data from CSV, which was interesting as well. > Ideally, this functionality would work for any example in the archetype, > shell, mapreduce whatever. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ACCUMULO-2111) Allow AccumuloClassLoader to use shell globbing
Sean Busbey created ACCUMULO-2111: - Summary: Allow AccumuloClassLoader to use shell globbing Key: ACCUMULO-2111 URL: https://issues.apache.org/jira/browse/ACCUMULO-2111 Project: Accumulo Issue Type: Improvement Components: start Affects Versions: 1.5.0, 1.4.4 Reporter: Sean Busbey Assignee: Sean Busbey Right now, the classpath parsing for hte AccumuloClassLoader supports * non-file URLs * paths to a jar file * paths to a directory * paths with regex matching at the file level This behavior is undocumented and incompatible with the output of other ecosystem tools, most importantly the "[hadoop classpath|http://hadoop.apache.org/docs/r1.0.4/commands_manual.html#classpath]"; command. that command may use shell globbing (depending on the hadoop distro). Proposed solution: * abstract the matching behavior * add matching by shell globbing * add a flag that determines if regex, globbing, or both (regex falling back to globbing) is used the flag should default to regex to maintain current out-of-the-box behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2097) Add ability to load when from script when MiniAccumuloCluster starts up
[ https://issues.apache.org/jira/browse/ACCUMULO-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858922#comment-13858922 ] Josh Elser commented on ACCUMULO-2097: -- bq. I'm already working on the CSV/TSV part, even though there is not a JIRA for it yet. Do you want to wait for me to finish that so you can integrate it in, or do you have different plans? /me facepalm I just worked up a bunch of stuff last night too, haha. I was making something standalone and then going to see how/where it makes sense to merge it in. Lemme push my stuff to Github for now. > Add ability to load when from script when MiniAccumuloCluster starts up > --- > > Key: ACCUMULO-2097 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2097 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > It would be helpful to be able load data from a script when the > MiniAccumuloCluster starts up from the instamo-archetype generated project. > I was thinking something like the -f option from the shell which simply runs > commands. My idea here is that it is easy to load that same file on a real > cluster and have the same data used in testing. I have written something > like this in the past that parsed the file and created mutations. > [~elserj] suggested loading data from CSV, which was interesting as well. > Ideally, this functionality would work for any example in the archetype, > shell, mapreduce whatever. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2097) Add ability to load when from script when MiniAccumuloCluster starts up
[ https://issues.apache.org/jira/browse/ACCUMULO-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858920#comment-13858920 ] Mike Drob commented on ACCUMULO-2097: - [~elserj] - I'm already working on the CSV/TSV part, even though there is not a JIRA for it yet. Do you want to wait for me to finish that so you can integrate it in, or do you have different plans? > Add ability to load when from script when MiniAccumuloCluster starts up > --- > > Key: ACCUMULO-2097 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2097 > Project: Accumulo > Issue Type: Improvement > Components: instamo-archetype >Reporter: Michael Wall >Assignee: Josh Elser >Priority: Minor > > It would be helpful to be able load data from a script when the > MiniAccumuloCluster starts up from the instamo-archetype generated project. > I was thinking something like the -f option from the shell which simply runs > commands. My idea here is that it is easy to load that same file on a real > cluster and have the same data used in testing. I have written something > like this in the past that parsed the file and created mutations. > [~elserj] suggested loading data from CSV, which was interesting as well. > Ideally, this functionality would work for any example in the archetype, > shell, mapreduce whatever. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858879#comment-13858879 ] Bill Havanki commented on ACCUMULO-2030: I'll create a second patch today. I cannot duplicate the getAuthorizationsBB issue that [~ctubbsii] found. I tried javadoc under 1.6 and 1.7. I only see one constructor for Authorizations that takes a List, but I'm fairly sure I've pulled the latest. > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2109) functional tests do not clean up generated test site.xml files
[ https://issues.apache.org/jira/browse/ACCUMULO-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858815#comment-13858815 ] Sean Busbey commented on ACCUMULO-2109: --- I try to minimize change sizes, especially when we have to merge through 2 branches. > functional tests do not clean up generated test site.xml files > -- > > Key: ACCUMULO-2109 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2109 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.5, 1.5.1 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > Attachments: ACCUMULO-2109.1.patch.txt > > > the tearDown code for the functional tests tries to delete the generated > accumulo-site.xml file from $ACCUMULO_HOME/conf, even though they are > generated in $ACCUMULO_CONF_DIR. > When these are not pointing to the same place, the files are left behind. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (ACCUMULO-2109) functional tests do not clean up generated test site.xml files
[ https://issues.apache.org/jira/browse/ACCUMULO-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858794#comment-13858794 ] Mike Drob edited comment on ACCUMULO-2109 at 12/30/13 1:42 PM: --- Why not use the existing path created at line 83? Edit: Because it refers to a different file. Revised query: Why not refactor the references on 264 and 458 out into a single variable? was (Author: mdrob): Why not use the existing path created at line 83? > functional tests do not clean up generated test site.xml files > -- > > Key: ACCUMULO-2109 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2109 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.5, 1.5.1 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > Attachments: ACCUMULO-2109.1.patch.txt > > > the tearDown code for the functional tests tries to delete the generated > accumulo-site.xml file from $ACCUMULO_HOME/conf, even though they are > generated in $ACCUMULO_CONF_DIR. > When these are not pointing to the same place, the files are left behind. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2027) ZooKeeperInstance.close() not freeing resources in multithreaded env
[
https://issues.apache.org/jira/browse/ACCUMULO-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858797#comment-13858797
]
Mike Drob commented on ACCUMULO-2027:
-
[~bills] - Sure, I'm not going to argue against the correctness of the code.
I'm more worried about 'surprising' behaviour from a client perspective, even
if said behaviour is not inherently wrong.
This isn't a performance critical piece, until it becomes your bottleneck. Does
this change cause that? I have no idea, but like you said, data is better than
conjecture. My default presumption just happens to sit on the other side of the
fence from yours.
> ZooKeeperInstance.close() not freeing resources in multithreaded env
>
>
> Key: ACCUMULO-2027
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2027
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: William Slacum
>Priority: Critical
> Fix For: 1.4.5, 1.5.1, 1.6.0
>
>
> While looking at the changes related to ZooKeeperInstance.close() in the
> 1.4.5-SNAPSHOT branch I noticed there were race conditions where resources
> were not properly released. One type of race condition is where a thread is
> between a closed check in ZooKeeperInstance and calling a ZooCache method
> when ZooKeeperInstance.close() is called. The following is an example
> situation
> # Thread 1 uses ZooKeeperInstance1 to get a zoocache.
> # Thread 2 calls close() on ZooKeeperInstnce1 which calls close() on zoocache
> # Thread 1 uses the zoocache it has reference to, causing a new zookeeper
> connection to be created.
> Below is an example program that will trigger this behavior. For me this
> little example program reliably shows a connected zookeeper after all of the
> threads die. If I use 0 threads it will show a closed zookeeper connection
> at the end.
> {code:java}
> static class WriteTask implements Runnable {
> private BatchWriter writer;
> private Random rand;
> WriteTask(Connector conn) throws TableNotFoundException {
> rand = new Random();
> writer = conn.createBatchWriter("foo5", 1000, 3, 1);
> }
> @Override
> public void run() {
> try {
> while (true) {
> Mutation m1 = new Mutation(String.format("%06d",
> rand.nextInt(100)));
> m1.put(String.format("%06d", rand.nextInt(100)),
> String.format("%06d", rand.nextInt(100)), String.format("%06d",
> rand.nextInt(100)));
> writer.addMutation(m1);
> writer.flush();
> }
> } catch (Exception e) {
> System.out.println(e.getMessage());
> }
> }
> }
> static class ReadTask implements Runnable {
> private Scanner scanner;
> ReadTask(Connector conn) throws TableNotFoundException {
> scanner = conn.createScanner("foo5", new Authorizations());
> }
> @Override
> public void run() {
> try {
> while (true) {
> for (Entry entry : scanner) {
> }
> }
> } catch (Exception e) {
> System.out.println(e.getMessage());
> }
> }
> }
> @Test(timeout = 3)
> public void test2() throws Exception {
> ZooKeeperInstance zki = new ZooKeeperInstance(accumulo.getInstanceName(),
> accumulo.getZooKeepers());
> Connector conn = zki.getConnector("root", "superSecret");
> conn.tableOperations().create("foo5");
> ArrayList threads = new ArrayList();
> int numThreads = 10;
> for (int i = 0; i < numThreads; i++) {
> Thread t = new Thread(new WriteTask(conn));
> t.start();
> threads.add(t);
> }
> for (int i = 0; i < numThreads; i++) {
> Thread t = new Thread(new ReadTask(conn));
> t.start();
> threads.add(t);
> }
> // let threads get spun up
> Thread.sleep(1000);
> ZooSession.printSessions();
> zki.close();
> // wait for the threads to die
> for (Thread thread : threads) {
> thread.join();
> }
> ZooSession.printSessions();
> }
> {code}
> Below are some changes I made to ZooSession for debugging purposes.
> {noformat}
> diff --git
> a/src/core/src/main/java/org/apache/accumulo/core/zookeeper/ZooSession.java
> b/src/core/src/main/java/org/apache/accumulo/core/zookeeper/ZooSession.java
> index b3db26f..475a21d 100644
> ---
> a/src/core/src/main/java/org/apache/accumulo/core/zookeeper/ZooSession.java
> +++
> b/src/core/src/main/java/org/apache/accumulo/core/zookeeper/ZooSession.java
> @@ -20,6 +20,8 @@
> import java.net.UnknownHostException;
> import java.util.HashMap;
> import java.util.Map;
> +import java.util.Map.Entry;
> +import java.util.Set;
>
> import org.apache.accumulo.core.util.UtilWaitThread;
> import org.apache.log4j.Logger;
> @@ -29,7 +
[jira] [Commented] (ACCUMULO-2109) functional tests do not clean up generated test site.xml files
[ https://issues.apache.org/jira/browse/ACCUMULO-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858794#comment-13858794 ] Mike Drob commented on ACCUMULO-2109: - Why not use the existing path created at line 83? > functional tests do not clean up generated test site.xml files > -- > > Key: ACCUMULO-2109 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2109 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.5, 1.5.1 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > Attachments: ACCUMULO-2109.1.patch.txt > > > the tearDown code for the functional tests tries to delete the generated > accumulo-site.xml file from $ACCUMULO_HOME/conf, even though they are > generated in $ACCUMULO_CONF_DIR. > When these are not pointing to the same place, the files are left behind. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (ACCUMULO-2030) Javadoc: core/security
[ https://issues.apache.org/jira/browse/ACCUMULO-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob reopened ACCUMULO-2030: - > Javadoc: core/security > -- > > Key: ACCUMULO-2030 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2030 > Project: Accumulo > Issue Type: Improvement > Components: docs >Reporter: Bill Havanki >Assignee: Bill Havanki >Priority: Trivial > Labels: documentation, javadoc > Fix For: 1.6.0 > > Attachments: ACCUMULO-2030.patch > > > Author javadoc for org.apache.accumulo.core.security classes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-1944) Cobertura not working for functional tests in 1.5.x and earlier
[ https://issues.apache.org/jira/browse/ACCUMULO-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858728#comment-13858728 ] Bill Havanki commented on ACCUMULO-1944: Current patch only applies to 1.4.5-SNAPSHOT. Working on testing patch for 1.5.1-SNAPSHOT. > Cobertura not working for functional tests in 1.5.x and earlier > --- > > Key: ACCUMULO-1944 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1944 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.4, 1.5.0 >Reporter: Bill Havanki >Assignee: Bill Havanki > Labels: cobertura, testing > Attachments: ACCUMULO-1944.patch > > > The -C argument to test/system/auto/run.py should enable running instrumented > functional tests to analyze coverage using Cobertura. The capability is not > functional; code is not instrumented even when Cobertura is available, and > tests are not run with the instrumented code. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ACCUMULO-1944) Cobertura not working for functional tests in 1.5.x and earlier
[ https://issues.apache.org/jira/browse/ACCUMULO-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Havanki updated ACCUMULO-1944: --- Attachment: ACCUMULO-1944.patch > Cobertura not working for functional tests in 1.5.x and earlier > --- > > Key: ACCUMULO-1944 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1944 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.4.4, 1.5.0 >Reporter: Bill Havanki >Assignee: Bill Havanki > Labels: cobertura, testing > Attachments: ACCUMULO-1944.patch > > > The -C argument to test/system/auto/run.py should enable running instrumented > functional tests to analyze coverage using Cobertura. The capability is not > functional; code is not instrumented even when Cobertura is available, and > tests are not run with the instrumented code. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
