distributed lock can get stuck at state 1 after bad connections

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • None
    • Affects Version/s: 2.7.5
    • Component/s: Sharding
    • Fully Compatible
    • ALL
    • Sharding 2 04/24/15, Sharding 3 05/15/15, Sharding 4 06/05/15, Sharding 5 06/26/16, Sharding 8 08/28/15, Sharding 9 (09/18/15), Sharding 16 (06/24/16), Sharding 17 (07/15/16)
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      If a thread sets the state to 1* but aborted (with socket exceptions) before it fully claims the lock, it can block all other threads from acquiring the lock as long as it keeps on updating the lock ping.

      * For this issue to happen, the other threads who were also able to successfully modify the state to 1 should have a lower ts than the thread who aborted.

            Assignee:
            Randolph Tan
            Reporter:
            Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: