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