hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-16105) LLAP: refactor executor pool to not depend on RejectedExecutionEx for preemption
Date Fri, 03 Mar 2017 19:50:45 GMT

     [ https://issues.apache.org/jira/browse/HIVE-16105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sergey Shelukhin updated HIVE-16105:
------------------------------------
    Description: There's a queue inside the threadpool consisting of one item (that's how
we set it up), which means that we can submit N+1 tasks and not get rejected, with one task
still not running and no preemption happening (note that SyncQueue we pass in does not in
fact block in TP, because TP calls offer not put; and if it did, preemption would never trigger
at all because the only thread adding stuff to the TP would be blocked until the item was
gone from the queue, meaning that there'd never be a rejection). Having a threadpool like
this also limits our options to e.g. move the task that is being killed out immediately to
start another one (that itself is out of the scope of this jira)  (was: There's a queue inside
the threadpool consisting on one item (that's how we set it up), which means that we can submit
N+1 tasks and not get rejected, with one task still not running and no preemption happening.
Having a threadpool like this also limits our options to e.g. move the task that is being
killed out immediately to start another one (that itself is out of the scope of this jira))

> LLAP: refactor executor pool to not depend on RejectedExecutionEx for preemption
> --------------------------------------------------------------------------------
>
>                 Key: HIVE-16105
>                 URL: https://issues.apache.org/jira/browse/HIVE-16105
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>
> There's a queue inside the threadpool consisting of one item (that's how we set it up),
which means that we can submit N+1 tasks and not get rejected, with one task still not running
and no preemption happening (note that SyncQueue we pass in does not in fact block in TP,
because TP calls offer not put; and if it did, preemption would never trigger at all because
the only thread adding stuff to the TP would be blocked until the item was gone from the queue,
meaning that there'd never be a rejection). Having a threadpool like this also limits our
options to e.g. move the task that is being killed out immediately to start another one (that
itself is out of the scope of this jira)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message