[
https://issues.apache.org/jira/browse/ACCUMULO-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029865#comment-16029865
]
Ivan Bella commented on ACCUMULO-4643:
--------------------------------------
[~kturner] You are correct in that whatever key gets sent back with the
exception (or the "interrupt" key) would have to be transformed. In fact it
would need contain enough information such that the subsequent seek invocation
(using that key as the start of the range, non-inclusive) will allow the seek
to continue where it left off. Option #2 seemed simpler to implement
initially. I am going to implement an option #3 where I create a interface
that can be used to extend an SKVI with methods to implement this concept
instead of using an exception. Option #1 seemed like a potential performance
problem as we would need to check the class of the returned key on every cycle.
It is thought that an iterator that yields using an exception would only be
implemented with iterators that may do a lot of work for no gain and hence this
would happen infrequently.
> Allow iterators to interrupt themselves
> ---------------------------------------
>
> Key: ACCUMULO-4643
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4643
> Project: Accumulo
> Issue Type: Improvement
> Components: tserver
> Affects Versions: 1.8.1, 2.0.0
> Reporter: Ivan Bella
> Assignee: Ivan Bella
> Labels: features
> Fix For: 2.0.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> The idea here is to allow an iterator stack to send back a special key or
> throw a special exception which will allow the tablet server to tear down the
> scan to be rebuilt later. This is to handle the case where an iterator is
> doing a lot of work without returning results to avoid starving out other
> scans.
> There are two thoughts on how to do this:
> 1) A special "interrupt" key is returned from the getTopKey call that is
> detected in the Tablet.nextBatch call, is not added to the results, but is
> used to add an unfinished range and results in the remaining ranges to be
> deemed unfinished.
> 2) An special exception is thrown from the next or seek call that included
> the key of the current position, and the same actions are taken as in 1).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
