Accumulo-1.7 - Build # 306 - Aborted
The Apache Jenkins build system has built Accumulo-1.7 (build #306) Status: Aborted Check console output at https://builds.apache.org/job/Accumulo-1.7/306/ to view the results.
[jira] [Resolved] (ACCUMULO-4514) Remove unnecessary code
[ https://issues.apache.org/jira/browse/ACCUMULO-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-4514. - Resolution: Fixed Fix Version/s: (was: 1.8.1) (was: 2.0.0) Only applied patch to 1.7 branch (for 1.7.3). Merging forward to 1.8 and master branches did not result in any changes to those branches (there were no warnings to fix in 1.8 and master). > Remove unnecessary code > --- > > Key: ACCUMULO-4514 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4514 > Project: Accumulo > Issue Type: Task >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs >Priority: Trivial > Fix For: 1.7.3 > > > This is a trivial task to clean up unnecessary code. Specifically, to use > diamond operators where possible on the 1.7 branch, and to remove unused > imports leftover from previous code changes. > This will make merging to newer branches easier (to reduce conflicts) where > diamond operators are already in heavy use, and it will establish some more > style consistency across branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637754#comment-15637754 ] Josh Elser commented on ACCUMULO-4502: -- re impact -- http://brooker.co.za/blog/2012/09/10/volatile.html tl;dr for a volatile variable under contention, read performance, with a high variance, can be impacted by 25x and write perf by 100x. Heavily variant due to multi-core and cache lines. I'll see if I can find some time tonight or this weekend to dig into this code myself since you made time to do the same, Ivan. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637594#comment-15637594 ] Josh Elser commented on ACCUMULO-4502: -- bq. I need the community to verify that my logic is sound and that this is a possible hole. Understood. As you described it, I would concur with you, but I am by no means an expert in this portion of the codebase. bq. I can guarantee this does not break anything, but I cannot yet guarantee it fixes the problem. :) My concern would be the performance impact of marking these variables (potentially unnecessarily) volatile. I don't have a good quantification of the impact WRT our invocation (need to educate myself). Maybe [~kturner] has some opinions. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637584#comment-15637584 ] Ivan Bella commented on ACCUMULO-4502: -- I can guarantee this does not break anything, but I cannot yet guarantee it fixes the problem. It might take me a little while to get it onto a system that has shown this issue, and then a while before I can say it has fixed the issue. I need the community to verify that my logic is sound and that this is a possible hole. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACCUMULO-4514) Remove unnecessary code
Christopher Tubbs created ACCUMULO-4514: --- Summary: Remove unnecessary code Key: ACCUMULO-4514 URL: https://issues.apache.org/jira/browse/ACCUMULO-4514 Project: Accumulo Issue Type: Task Reporter: Christopher Tubbs Assignee: Christopher Tubbs Priority: Trivial Fix For: 1.7.3, 1.8.1, 2.0.0 This is a trivial task to clean up unnecessary code. Specifically, to use diamond operators where possible on the 1.7 branch, and to remove unused imports leftover from previous code changes. This will make merging to newer branches easier (to reduce conflicts) where diamond operators are already in heavy use, and it will establish some more style consistency across branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637563#comment-15637563 ] Josh Elser commented on ACCUMULO-4502: -- bq. Access is synchronized appropriately in the SourceSwitchingIterator, but this would result in one thread setting a member variable and another one using immediately afterwards. Ahh, ok. Access to the HeapIterator is synchronized properly, just we might still hit this value visibility issue when switching. Sounds plausible. Nice digging! I can't imagine the ease of testing this. Have you been able to test this out on a real installation (where you were originally seeing this problem)? > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637558#comment-15637558 ] Ivan Bella commented on ACCUMULO-4502: -- The switchSource is definitly done on a separate thread during minor compaction. So the answer would be yes. Access is synchronized appropriately in the SourceSwitchingIterator, but this would result in one thread setting a member variable and another one using immediately afterwards. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637389#comment-15637389 ] Josh Elser commented on ACCUMULO-4502: -- Is a single instance of HeapIterator used concurrently by multiple threads? I honestly don't know, but it strikes me as rather odd. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4502) Called next when there is no top
[ https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637382#comment-15637382 ] Ivan Bella commented on ACCUMULO-4502: -- After an exhaustive search through this code, the only reason I can come up with is an issue with a member reference in the underlying HeapIterator. The scenario would be as follows: thread 1: calls hasTop() which is invoked on then in memory data source thread 2: calls switchSource which sets up the new datasource and calls seek which results in topIdx being set thread1: calls next() which gets a value of null for topIdx So if topIdx is marked as volatile then this should not happen. > Called next when there is no top > > > Key: ACCUMULO-4502 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4502 > Project: Accumulo > Issue Type: Bug > Components: core, tserver >Affects Versions: 1.6.6 >Reporter: Ivan Bella >Assignee: Ivan Bella > Fix For: 1.7.3, 1.8.1, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This happens very rarely but we have seen the following exception (pulled > from a server running 1.6.4). Looking at the code I believe this condition > can still happen in 1.8.0: > java.util.concurrent.ExecutionException: java.lang.IllegalStateException: > Called next() when there is no top > ... > Caused by: java.lang.IllegalStateException: Called next() when there is no top > HeapIterator.next(HeapIterator.java: 77) > WrappingIterator.next(WrappingIterator.java: 96) > MemKeyConversionIterator.next(InMemoryMap.java:162) > SourceSwitchingIterator.readNext(SourceSwitchingIterator.java: 139) > SourceSwitchingIterator.next(SourceSwitchingIterator.java: 123) > PartialMutationSkippingIterator.consume(InMemoryMap.java:108) > SkippingIterator.seek(SkippingIterator.java:43) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4513) Master hangs if shutdown requested while in state "HAS_LOCK"
[ https://issues.apache.org/jira/browse/ACCUMULO-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637086#comment-15637086 ] John Vines commented on ACCUMULO-4513: -- I believe this more prominent on systems with multiple masters in the event of the main master going down when stopAll has been issued. > Master hangs if shutdown requested while in state "HAS_LOCK" > > > Key: ACCUMULO-4513 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4513 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.6, 1.7.2 >Reporter: John Vines >Priority: Critical > > The StatusThread.run() method does not have any means to change the masters > state out of HAS_LOCK when CLEAN_STOP is requested, which can cause the > master to get perpetually stuck > Additionally, because the master never hit the NORMAL state, the main > Master.run() was jammed at waitForMetadataUpgrade.await() so the thrift > server was never started and shutdown couldn't be issued directly (not > entirely confident that would have actually fixed anything though this is > contrary to the the state transition chart which says we can go from > HAVE_LOCK->STOP) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Accumulo-Pull-Requests - Build # 519 - Aborted
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #519) Status: Aborted Check console output at https://builds.apache.org/job/Accumulo-Pull-Requests/519/ to view the results.
Accumulo-Pull-Requests - Build # 518 - Failure
The Apache Jenkins build system has built Accumulo-Pull-Requests (build #518) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-Pull-Requests/518/ to view the results.
