[ 
https://issues.apache.org/jira/browse/ACCUMULO-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029818#comment-16029818
 ] 

Keith Turner commented on ACCUMULO-4643:
----------------------------------------

I was thinking about the use case of an iterator that does some type of 
transform.  If not handled properly, this feature could lead to that iterator 
being reseeked with an untransformed key from an iterator below it.  Where 
normally its only reseeked with transformed keys.  

For option #1, was the idea to add a interrupt boolean field to Key (like the 
delete boolean)? If so, then the iterator doing transformation would have to 
ensure it sets the interrupt field on the transformed key.  For option 2, any 
iterator doing transformations should catch the exception, transform the key, 
and then thrown a new exception with the transformed key.

> 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
>  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)

Reply via email to