[
https://issues.apache.org/jira/browse/ACCUMULO-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643088#comment-15643088
]
Josh Elser commented on ACCUMULO-4502:
--------------------------------------
Alright, I have one question for you, [~ivan.bella]. I apologize in advance if
I'm just missing it (going cross-eyed following this execution path).
In the example you listed:
{quote}
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
{quote}
In this case, there's a HeapIterator (really, a MultiIterator, I guess) which
contains some zero to many FileSKIIterators and a MemoryIterator. Like you say,
when the memDump happens in the InMemoryMap, all of the current MemoryIterators
referencing that memory segment in the IMM (from multiple scans) are
re-initialized to use the local memdump file and then re-seek()'ed.
The thing I'm struggling with is: how is the HeapIterator re-heapified after
the switchSource() and "results in topIdx being set" as you said? Best as I can
tell, it isn't. The heap wouldn't be consulted until the next time next() is
called. This makes sense, in terms of the HeapIterator, as this switch of "data
source" should be transparent. The HeapIterator shouldn't have to re-heap just
because we switched from memory to disk and the topIdx shouldn't change. Can
you point me to the code where this happens per your explanation? I assume I'm
just missing something. Thanks!
> 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)
