[
https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514548#comment-16514548
]
Pooja Nilangekar commented on IMPALA-6153:
------------------------------------------
I looked at the code and spoke to [~sailesh] this morning.
One approach would be to added a reader/writer lock in the Coordinator. Each
time the UpdateFilter function gets called, it would hold a reader lock
throughout its execution and the ReleaseExecResources function would have to
acquire a writer lock instead of the filter_lock_. I wanted to check if you
think this approach would suffice or should I explore other directions?
> 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]
