accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3348) Interrupt the ScanTask's thread when the Session is cancelled.
Date Wed, 19 Nov 2014 22:26:33 GMT

    [ 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)

Mime
View raw message