accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Bella (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4643) Allow iterators to interrupt themselves
Date Tue, 30 May 2017 20:36:05 GMT

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

Ivan Bella commented on ACCUMULO-4643:
--------------------------------------

After a lengthy discussion with [~kturner], we came to the conclusion that if this mechanism
is put in place then iterators that implement a yielding mechanism can only be called from
iterators that are aware of that fact.  Hence a separate interface (or perhaps changing SKVI)
that has methods something like the following would be better:

// Called to tell an iterator that yielding is supported.
public void setYieldSupported();
// Called after every next and seek call to determine it has yielded
public boolean hasYielded();
// Called after hasYielded returns true to determine the key to re-seek to later
public Key getYieldPosition();

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

Mime
View raw message