[
https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
