Log each operation that holds a lock for an extended period of time without yielding

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Won't Do
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Diagnostics, Logging
    • None
    • Storage Execution
    • Execution Team 2021-11-01, Execution Team 2021-11-15, Execution Team 2021-11-29, Execution Team 2021-12-13, Execution Team 2021-12-27, Execution Team 2022-01-10, Execution Team 2022-01-24, Execution Team 2022-02-07, Execution Team 2022-02-21, Execution Team 2022-10-17, Execution Team 2022-10-31
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Anything that holds a lock for an extended period of time without yielding is a potential performance problem. An extended period of time might be 1 second but should be configurable for debugging purposes or if this creates too much noise in the logs.

      The unlock code should know how long the lock has been held and also know which connection this happens on so it will give us more information tying it back to the offending operation.

              Assignee:
              [DO NOT USE] Backlog - Storage Execution Team
              Reporter:
              Dmitry Agranat
              Votes:
              8 Vote for this issue
              Watchers:
              28 Start watching this issue

                Created:
                Updated:
                Resolved: