[
https://issues.apache.org/jira/browse/ACCUMULO-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945846#comment-13945846
]
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: https://issues.apache.org/jira/browse/ACCUMULO-2542
> 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 important.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
