[infinispan-issues] [JBoss JIRA] (ISPN-8741) ClusteredLockSplitBrainTest fails randomly

[Katia Aresti (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-8741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Katia Aresti updated ISPN-8741:
-------------------------------
    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.



> ClusteredLockSplitBrainTest fails randomly
> ------------------------------------------
>
>                 Key: ISPN-8741
>                 URL: https://issues.jboss.org/browse/ISPN-8741
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Clustered Locks
>    Affects Versions: 9.2.0.CR1
>            Reporter: Katia Aresti
>            Assignee: Katia Aresti
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)