[
https://issues.apache.org/jira/browse/IMPALA-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-8597:
----------------------------------
Component/s: Backend
> Improve session maintenance timing logic
> ----------------------------------------
>
> Key: IMPALA-8597
> URL: https://issues.apache.org/jira/browse/IMPALA-8597
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Reporter: Thomas Tauber-Marshall
> Priority: Major
>
> Currently, the coordinator maintains a list of the timeout lengths for all
> sessions that have an idle_session_timeout set. The original intention of
> this was to have the thread that checks for timeouts wake up at an interval
> of <the shortest currently registered timeout> / 2, but this resulted in
> IMPALA-5108
> The fix for that bug changed the session maintenance thread wake up every 1
> second if any timeout is registered, but we still maintain the list of
> timeout values even though only the length of the list is ever used.
> Given that the default config is for there to be no session timeouts and that
> the maintenance thread is somewhat inefficient in holding the
> session_state_map_ lock for almost its entire execution, we may want to keep
> the behavior of only waking up once per second if there are any registered
> timeouts, in which case it would be more efficient to just maintain a count
> of timeouts instead of the list.
> Or, we may want to just simplify the logic and have the thread always wake up
> once per second, without tracking the registered timeouts at all (esp. with
> the new work in IMPALA-1653 which adds closing of disconnected sessions to
> the maintenance thread), in which case we might want to consider ways to
> avoid holding the session_state_map_ lock for so long, eg. by sharding it the
> way we did with the client_request_state_map_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
