[
https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514572#comment-16514572
]
Tim Armstrong commented on IMPALA-6153:
---------------------------------------
Yeah I agree with Dan. I think the reader/writer lock would have the right
effect (I think?) but we should have a clear explanation for how it fits into
the state machine of the class and then see if the reader/writer lock is the
simplest possible mechanism to achieve the effect.
I think there's one tricky issue around liveness that we should think through.
Potentially a thread in UpdateFilter could be in an RPC and take a while to
exit and clean itself up. Blocking progress of another thread can have other
consequences, e.g. if it's being called from an RPC handler. It might be the
right thing to do, but we should make sure to do the right thing.
> 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]
