[
https://issues.apache.org/jira/browse/IMPALA-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776607#comment-16776607
]
ASF subversion and git services commented on IMPALA-7163:
---------------------------------------------------------
Commit f823c46099aef28fe01c7348f8bd94c11b7fb7d3 in impala's branch
refs/heads/2.x from Sailesh Mukil
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=f823c46 ]
IMPALA-7215: Implement a templatized CountingBarrier
Currently, our CountingBarrier util only notifies a 'bool' value
and uses an underlying Promise<bool>.
We're seeing cases in code where we might want to be notified of a
different kind of Promise (other than bool). We add a templatized
class TypedCountingBarrier<T> and convert CountingBarrier to use the
TypedCountingBarrier<T> internally.
This was identified while working on IMPALA-7163.
Testing: Ran 'core' tests.
Change-Id: I05fc79228250408ae16481ae7ff3491a90d26b8e
Reviewed-on: http://gerrit.cloudera.org:8080/10827
Reviewed-by: Sailesh Mukil <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Implement a state machine for the QueryState class
> --------------------------------------------------
>
> Key: IMPALA-7163
> URL: https://issues.apache.org/jira/browse/IMPALA-7163
> Project: IMPALA
> Issue Type: Sub-task
> Components: Distributed Exec
> Reporter: Sailesh Mukil
> Assignee: Sailesh Mukil
> Priority: Major
> Fix For: Impala 3.1.0
>
>
> We've recently been improving our query lifecycle by adding explicit state
> transitions so it's easier to reason about what should happen at a given
> stage in the lifetime of a query or a fragment instance.
> On the coordinator side. The coordinator's view of the query:
> https://github.com/apache/impala/commit/6ca87e46736a1e591ed7d7d5fee05b4b4d2fbb50
> On the fragment instance state side. A FIS's view of its own execution:
> https://github.com/apache/impala/blob/e12ee485cf4c77203b144c053ee167509cc39374/be/src/runtime/fragment-instance-state.h#L182-L203
> We don't have something like this for the QueryState class which maintains
> query wide state per executor. Adding it should make the lifecycle of a query
> from an executors point of view much easier to reason about.
> Additional info: This was identified as part of work for
> IMPALA-2990/IMPALA-4063, and is a precursor to it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
