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

    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

          is related to

          New Feature - A new feature of the product, which has yet to be developed. KUDU-430 Consistent Operations

          • Major - Major loss of function.
          • Open

          Activity

            People

              Unassigned Unassigned
              dralves David Alves
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: