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

Yong Deng (Jira) issues at jboss.org
Wed Jul 31 06:54:00 EDT 2019


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

Yong Deng commented on JGRP-2364:
---------------------------------

Following is the temporary fix on my side in org.jgroups.protocols.Locking.ClientLock#_unlock. I add 10 seconds timeout in order not to hang when we hit other JGroups bugs and RELEASE_LOCK_OK is not sent back ever.
{code:java}
        protected synchronized void _unlock(boolean force) {
            if(!acquired && !denied && !force)
                return;
            this.timeout=0;
            this.is_trylock=false;
            if (!denied) {
                if (!force)
                    addToPendingReleaseRequests(this);
                sendReleaseLockRequest(name, lock_id, owner);// lock will be released on RELEASE_LOCK_OK response
                if (force && removeClientLock(name, owner))
                    notifyLockDeleted(name);
                if (!force) {
                    //unlock will return only when get RELEASE_LOCK_OK or timeLeft after some seconds
                    long timeLeft = 10000;
                    while (acquired || denied) {
                        long start = System.currentTimeMillis();
                        try {
                            wait(timeLeft);
                        } catch (InterruptedException ie) {
                            break;
                        }
                        long duration = System.currentTimeMillis() - start;
                        if (duration > 0)
                            timeLeft -= duration;
                        if (timeLeft <= 0) {
                            if (log.isWarnEnabled()) {
                                log.warn(format("[%s]: timeout wait for RELEASE_LOCK_OK response for lock=%s", local_addr, this));
                            }
                            //defensive fix
                            acquired = denied = false;
                            break;
                        }
                    }
                }
            }
            else
                _unlockOK();
        }
{code}


> 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)



More information about the jboss-jira mailing list