[
https://issues.apache.org/jira/browse/KUDU-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KUDU-1697:
------------------------------
Labels: scalability (was: )
> Operations that have to wait for a certain time/condition to pass shouldn't
> block threads
> -----------------------------------------------------------------------------------------
>
> Key: KUDU-1697
> URL: https://issues.apache.org/jira/browse/KUDU-1697
> Project: Kudu
> Issue Type: Improvement
> Components: tserver
> Reporter: David Alves
> Priority: Major
> Labels: scalability
>
> Certain operations, like waiting for a scan timestamp to be "safe" before
> proceeding with the scan, or waiting in the context of commit-wait in the
> transaction manager can easily block threads which will starve all other work.
> Both these operation end up calling WaitUntilAfter() or
> WaitUntilAfterLocally() on the HybridClock. We should use a notification
> mechanism instead, i.e. NotifyMeAfter(ts, &callback, &thread_pool),
> NotifyMeAfterLocally(ts, &callback, &thread_pool).
> Similar reversals should likely be made on the MvccManager's
> WaitForCleanSnapshotAtTimestamp() and WaitForCleanSnapshot().
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
