Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-8741

ClusteredLockSplitBrainTest fails randomly

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 9.2.0.Final
    • 9.2.0.Final
    • Clustered Locks
    • None

      When it works
      ====
      node A acquires the lock
      Split brain of [A] [B, C, D]

      Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.

      With the view change listener, B calls unlock for A.

      The listener of B is notified that the lock is released.

      Retries for B

      It works, and A can't do anything else because it's not in the majority partition.

      When it fails
      ====
      node A acquires the lock
      Split brain of [A] [B, C, D]

      Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.

      With the view change listener, B calls unlock for A.

      The listener of B is notified that the lock is released.

      Retries for B

      It fails, because it says that actually the lock is still with locked by A in node D, but it is available in Node B and C.

      Another unlock is retried for Node D, and this works, and still tries to unlock B and C, which fail because now thy are locked by B.

      This gets on the limbo and the request is expired by the scheduler.

              karestig@redhat.com Katia Aresti
              karestig@redhat.com Katia Aresti
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: