[
https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547017#comment-16547017
]
Tim Armstrong commented on IMPALA-6153:
---------------------------------------
I agree it would be good if UpdateFilter() terminated early when exec_state_ is
not EXECUTING. It achieves something similar by checking whether the state is
disabled but our goal should be to explicitly tie it into the coordinator
lifecycle. It might also be useful to check this between PublishFilter() calls
so that it terminates more quickly (we achieve this indirectly by checking
whether the filter is disabled in PublishFilter() but it would be nice to make
the dependency on the exec state more explicit).
The trickier thing is whether we can add the invariant that
ReleaseExecResources() doesn't complete until there are no threads in
UpdateFilter(). I think we probably need some additional synchronisation here -
since I don't think synchronising on the exec state is sufficient to make the
below work.
# Threads A and B enters UpdateFilter()
# Thread C transitions coordinator to terminal state
# Thread C waits for thread A to exit
# Threads A and B notices exec state transition, exits UpdateFilter()
# Thread D enters UpdateFilter(), notices exec state has changed, exits
immediately.
# Thread C gets unblocked
I think we basically need something that counts the number of threads in
UpdateFilter() and then lets another thread block waiting for the thread count
to hit zero. shared_mutex does achieve this. Maybe we can switch filter_lock_
to a shared_mutex that is held in shared mode for the duration of
UpdateFilter() and exclusive mode in the filters where we currently hold
filter_lock_? I think that might be an elegant solution since we already
acquire filter_lock_ in ReleaseExecResources().
> 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]
