[jira] [Commented] (ACCUMULO-3348) Interrupt the ScanTask's thread when the Session is cancelled.

["Josh Elser (JIRA)" <ji...@apache.org>]

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

Josh Elser commented on ACCUMULO-3348:
--------------------------------------

The naive solution would be to get a reference to the thread running the ScanTask and call {{interrupt()}} on it. The problem is that the thread could still eat the interrupt and merrily continue on (I think we've identified that DFSClient does this sometimes in the past). I'm not sure if there's something stronger we could do if we can get a hook on the threadpool itself, much less what a more elegant solution would look like.

> Interrupt the ScanTask's thread when the Session is cancelled.
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-3348
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3348
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Josh Elser
>            Priority: Minor
>
> As far as I can tell, we have no means in the TabletServer which actively {{interrupt()}} a Thread which is running a Scan.
> As long as all of the Iterators in the ScanTask are actively making progress (fetching data from memory or disk), they'll see the interruptFlag which is set via {{InterruptibleIterator}}. This does not suffice if an Iterator is performing some long-running task or blocked on some external call which might hang/fail/pause/block/etc.
> In general, we've worked around this issue by recommending to "not do that": Iterators shouldn't access external resources or perform long-running computations (or do anything that won't return reliably). It would be better if we could make a stronger guarantee server-side about cleaning up ScanTasks and their iterator stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)