You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@hive.apache.org by "Siddharth Seth (JIRA)" <ji...@apache.org> on 2016/05/26 01:45:13 UTC

[jira] [Comment Edited] (HIVE-13858) LLAP: A preempted task can end up waiting on completeInitialization if some part of the executing code suppressed the interrupt

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

Siddharth Seth edited comment on HIVE-13858 at 5/26/16 1:44 AM:
----------------------------------------------------------------

Patch which should fix this.

1. It changes a 'aborted && interrupted' check to just say 'aborted'
2. It changes completeInitialization - to do a future.get with a timeout, and check the abort status between these waits.

cc [~prasanth_j], [~sershe]


was (Author: sseth):
Patch which should fix this.

1. It changes a 'aborted && interrupted' check to just say 'aborted'
2. It changes completeInitialization - to do a future.get with a timeout, and check the abort status between these waits.

> LLAP: A preempted task can end up waiting on completeInitialization if some part of the executing code suppressed the interrupt
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-13858
>                 URL: https://issues.apache.org/jira/browse/HIVE-13858
>             Project: Hive
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Siddharth Seth
>            Assignee: Siddharth Seth
>            Priority: Critical
>              Labels: llap
>         Attachments: HIVE-13858.01.patch
>
>
> An interrupt along with a HiveProcessor.abort call is made when attempting to preempt a task.
> In this specific case, the task was in the middle of HDFS IO - which 'handled' the interrupt by retrying. As a result the interrupt status on the thread was reset - so instead of skipping the future.get in completeInitialization - the task ended up blocking there.
> End result - a single executor slot permanently blocked in LLAP. Depending on what else is running - this can cause a cluster level deadlock.



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