[jira] [Updated] (KUDU-1697) Operations that have to wait for a certain time/condition to pass shouldn't block threads

["Grant Henke (Jira)" <ji...@apache.org>]

     [ 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)