[jboss-jira] [JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos

[Yong Deng (Jira)]

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

Yong Deng edited comment on JGRP-2364 at 8/3/19 10:42 AM:
----------------------------------------------------------

For your scenario step 4, _acquired_ and _denied_ were set to false, it will only affect ClientLock status. Before RELEASE_LOCK is processed by new coordinate B in step 5, no one would ever be able to acquire the lock X, right?

Setting _acquired_ and _denied_ to false is a defensive fix. Without this defensive fix, in case RELEASE_LOCK_OK is never sent back, this client lock will stay locked status for ever. The same thread can acquire the lock even it did not acquire the lock from the coordinate.


was (Author: dengyong):
For your scenario step 4, _acquired_ and _denied _ were set to false, it will only affect ClientLock status. Before RELEASE_LOCK is processed by new coordinate B in step 5, no one would ever be able to acquire the lock X, right?

Setting _acquired_ and _denied _ to false is a defensive fix. Without this defensive fix, in case RELEASE_LOCK_OK is never sent back, this client lock will stay locked status for ever. The same thread can acquire the lock even it did not acquire the lock from the coordinate.

> simply lock and unlock JGroups lock repeatedly will create chaos
> ----------------------------------------------------------------
>
>                 Key: JGRP-2364
>                 URL: https://issues.jboss.org/browse/JGRP-2364
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.1.1
>         Environment: JDK: 1.8
> JGroups: 4.1.1
> Lock: CENTRAL_LOCK
>            Reporter: Yong Deng
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.1.2
>
>         Attachments: LockSimpleTest.java
>
>
> I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?*
> * Current log:
> {code:java}
> 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000]
> 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A]
> 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> {code}
> * The expected log:
> {code:java}
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)