[jboss-jira] [JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

[Bela Ban (Jira)]

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

Bela Ban commented on JGRP-2299:
--------------------------------

Super, good to know!

Now that you're using distributed locks, it's time to talk about my dislike of distributed locks, especially in light of partitions, isn't it? :-)

> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
>                 Key: JGRP-2299
>                 URL: https://issues.jboss.org/browse/JGRP-2299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.15
>         Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
>            Reporter: Mirko Streckenbach
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.1.2
>
>         Attachments: JGroupsExample.java, image.png, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().



--
This message was sent by Atlassian Jira
(v7.13.5#713005)