[
https://issues.apache.org/jira/browse/ACCUMULO-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Berman resolved ACCUMULO-2542.
--------------------------------------
Resolution: Implemented
Thanks [~kturner], you're right, looks like this already works fine. Not sure
what was wrong with our original experiment, but I can't reproduce it now.
> 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)
