Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-1697

Operations that have to wait for a certain time/condition to pass shouldn't block threads

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • tserver

    Description

      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().

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            dralves David Alves

            Dates

              Created:
              Updated:

              Issue deployment