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

[David White (Jira)]

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

David White commented on JGRP-2299:
-----------------------------------

In my case we are using TCP, not UDP.

> 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.1
>
>         Attachments: JGroupsExample.java, 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.12.1#712002)