[
https://issues.apache.org/jira/browse/IMPALA-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558959#comment-16558959
]
Tim Armstrong commented on IMPALA-3882:
---------------------------------------
[~bikramjeet.vig] assigning since you're looking at this area. Feel free to
close if it's outdated.
> Fix some locking / concurrency issues in ImpalaServer and QueryExecState
> ------------------------------------------------------------------------
>
> Key: IMPALA-3882
> URL: https://issues.apache.org/jira/browse/IMPALA-3882
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
> Affects Versions: Impala 2.6.0
> Reporter: Henry Robinson
> Assignee: Bikramjeet Vig
> Priority: Minor
>
> Three related things can be improved fairly easily in {{QueryExecState}}. I
> found these when debugging hangs in the debug web pages during query
> planning.
> *1. Don't hold the lock during {{GetExecRequest()}}*
> Since planning can take a long time, the fact that {{ImpalaServer}} holds
> {{(*exec_state)->lock()}} during {{GetExecRequest()}} can lead to problems
> when any other process (like the client, or a debug page) tries to read the
> exec state object.
> There's no real reason to hold the exec state lock - the only reason given in
> the code is to make sure that exec state can't be read before the result
> metadata is set. But we can achieve that a different way by ensuring that all
> callers of {{result_metadata()}} wait for planning to be finished first.
> *2. Remove path in {{GetQueryExecState()}} that can take lock*
> It's confusing to have a path in {{ImpalaServer::GetQueryExecState()}} that
> allows callers to have the exec state returned with its lock held. The reason
> we might have this path is to ensure that there's no way that an exec state
> can be removed from the exec state map once it has been found - for example,
> if the query was cancelled after it was looked up in the exec state, but
> before it was returned to the caller. It's easier for callers to check that
> property explicitly after taking the lock for themselves.
> *3. Simplify implementation of {{QueryExecState::Wait()}}*
> {{QueryExecState::Wait()}} should use promises to have callers coordinate on
> the wait-thread's completion, rather than the more complex logic based on
> condvars that's there now. (There's more scope to improve the waiting path,
> but this is an incremental change).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
