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

ClusteredLockSplitBrainTest fails randomly

    Details

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  karesti Katia Aresti
                  Reporter:
                  karesti Katia Aresti
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: