[
https://issues.apache.org/jira/browse/ACCUMULO-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945697#comment-13945697
]
Josh Elser commented on ACCUMULO-2542:
--------------------------------------
Marc has done some work on this in the past
(https://github.com/phrocker/accumulo-stopscan). I remember him noting how this
was difficult because infrastructure for running that Scan will notice that it
"stopped" and then try to restart it again (usually one of the nice qualities
of fetching data). I'm not sure if he ever came up with a workaround for this
or chalked it up to needing to rework the solution.
> 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)
