[
https://issues.apache.org/jira/browse/IMPALA-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-8442:
----------------------------------
Description:
The handling of concurrent access to ClientRequestState::query_status_ is messy
- it's exposed directly via query_status() and a lot of callers don't hold
ClientRequestState::lock_.
This appears to be safe in many places for subtle reasons, e.g. because the
value won't be modified after a certain point in the query lifecycle, so it's
not dangerous to access it when logging an audit record. However this is
brittle and likely to lead with bugs if we change the code around it
signicantly.
We could approach this in various ways, e.g. updating callers to consistently
acquire the lock and/or documenting invariants around when its safe to do so
without holding it. Or we could make Status thread-safe, or have a thread-safe
Status wrapper.
was:
The handling of concurrent access to ClientRequestState::query_status_ is messy
- it's exposed directly via query_status() and a lot of callers don't hold
ClientRequestState::lock_.
This appears to be safe in many places for subtle reasons, e.g. because the
value won't be modified after a certain point in the query lifecycle, so it's
not dangerous to access it when logging an audit record. However this is
brittle and
We could approach this in various ways, e.g. updating callers to consistently
acquire the lock and/or documenting invariants around when its safe to do so
without holding it. Or we could make Status thread-safe, or have a thread-safe
Status wrapper.
> Clean up concurrency around query_status_
> -----------------------------------------
>
> Key: IMPALA-8442
> URL: https://issues.apache.org/jira/browse/IMPALA-8442
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Priority: Major
>
> The handling of concurrent access to ClientRequestState::query_status_ is
> messy - it's exposed directly via query_status() and a lot of callers don't
> hold ClientRequestState::lock_.
> This appears to be safe in many places for subtle reasons, e.g. because the
> value won't be modified after a certain point in the query lifecycle, so it's
> not dangerous to access it when logging an audit record. However this is
> brittle and likely to lead with bugs if we change the code around it
> signicantly.
> We could approach this in various ways, e.g. updating callers to consistently
> acquire the lock and/or documenting invariants around when its safe to do so
> without holding it. Or we could make Status thread-safe, or have a
> thread-safe Status wrapper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
