[jboss-jira] [JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever

[Bram Klein Gunnewiek (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531012#comment-13531012 ] 

Bram Klein Gunnewiek edited comment on JGRP-2234 at 2/9/18 4:47 AM:
--------------------------------------------------------------------

Not sure how it can be solved, but during a merge of [A,B] and [C,D] there are basically two locktables (of [A,B] and [C,D]). When merging those lock tables you can detect that both lock tables have an owner for lockX (lets say A and C both locked lockX). When B is the new coordinator of the merged cluster, you could implement it so that B saves both A and C as lockowner and only grants new lock() requests for lockX when both A and C performed an unlock();

I don't think its possible to take away locks, the only thing you could do is implement some sort of event system that fires an event when it detects that a lock has multiple holders after a cluster merge. This could be handled (or ignored) by the application using JGroups, I don't think its something JGroups itself can solve.


was (Author: bramklg):
Not sure how it can be solved, but during a merge of [A,B] and [C,D] there are basically two locktables (of [A,B] and [C,D]). When merging those lock tables you can detect that both lock tables have an owner for lockX (lets say A and C both locked lockX). Lets say B is the new coordinator of the merged cluster. You could implement it so that B saves both A and C as lockowner and only grants new lock() requests for lockX when both A and C performed an unlock();

I don't think its possible to take away locks, the only thing you could do is implement some sort of event system that fires an event when it detects that a lock has multiple holders after a cluster merge. This could be handled (or ignored) by the application using JGroups, I don't think its something JGroups itself can solve.

> Unlocked locks stay locked forever
> ----------------------------------
>
>                 Key: JGRP-2234
>                 URL: https://issues.jboss.org/browse/JGRP-2234
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bram Klein Gunnewiek
>            Assignee: Bela Ban
>             Fix For: 4.0.11
>
>         Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. 
> What we think is happening: 
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.



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