accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2542) Add mechanism to cancel scans
Date Mon, 24 Mar 2014 23:10:45 GMT


Keith Turner commented on ACCUMULO-2542:

Iterators are already interrupted, if this is not working for you we need to find out why.
  If an iterator is running in the background and a client does not ask about it status every
few seconds, it will be interrupted.   An atomic boolean will be set to true.  This atomic
boolean is checked when rfile blocks are read and when data is read from memory.  If its true
an exception is thrown.   If an iterators is in an infinite loop and not reading data from
sources, I am not sure what can be done.  There is ACCUMULO-1188.

To see the code for this in 1.4 look at what references {{o.a.a.core.iterators.IterationInterruptedException}}.
 Also take a look at {{o.a.a.server.tabletserver.TabletServer.ThriftClientHandler.continueScan()}}
 In continue scan it will wait one second for the background thread to return a result.  If
no result is returned in 1 sec, then it will return to the client.  Before returning to client
it will call {{sessionManager.removeIfNotAccessed(...)}}.  If the client does not come back
in a few seconds asking to continue the scan, then the scan will be cancelled.

> Add mechanism to cancel scans
> -----------------------------
>                 Key: ACCUMULO-2542
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Michael Berman
> ScannerBase.close() closes all connections to a given scan, but if there's an iterator
spinning on the scan, it will keep running at least until a record makes it all the way out
of the iterator stack.  If you have a bug in an iterator, or a filter that doesn't match anything,
or a combiner that matches everything, then that could mean scanning an entire table.  It
would be nice if there were some mechanism to interrupt that process.
> We probably couldn't do anything about a really buggy externally provided iterator that
just spins without calling next() downstream (short of calling Thread.close(), which is probably
a bad idea), but accumulo iterators could periodically check for cancellation and bail gracefully
(maybe each time we're about to load a new block?).  It would be nice to provide a mechanism
for external iterators to check their cancellation status so they can have an opportunity
to be well behaved if they're doing anything that might take a while, but that seems less

This message was sent by Atlassian JIRA

View raw message