[
https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514558#comment-16514558
]
Dan Hecht commented on IMPALA-6153:
-----------------------------------
We've been trying to clarify query lifecycle events and also differentiate
control structures from resources, rather than relying on adding ad-hoc locks.
Control structures remain alive for the life of the owning object (either
Coordinator on coordinator side or QueryState on executor side), whereas
resources are freed soon after query execution has finished. So I think we
should step back and see if we can rationalize the dependencies and what kind
of dependencies we really have, before resorting to adding a lock (not saying
we can't do that for sure, but let's consider the lifecycle of these things
first).
> Prevent Coordinator::UpdateFilter() running after query exec resources are
> released
> -----------------------------------------------------------------------------------
>
> Key: IMPALA-6153
> URL: https://issues.apache.org/jira/browse/IMPALA-6153
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Reporter: Sailesh Mukil
> Assignee: Pooja Nilangekar
> Priority: Major
> Labels: query-lifecycle, runtime-filters
>
> Coordinator::UpdateFilter() and CoordinatorBackendState::PublishFilter() run
> independent of the lifecycle of any fragment instance. This is problematic
> during query teardown.
> Specifically we should not release resources for a query if any one of those
> above functions are still running for that query and we also should not not
> start running the above methods after resources are released for the query.
> Also, the 'rpc_params' in UpdateFilter() could potentially hold large amounts
> of untracked memory, so we should track 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]
