[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=13773552#comment-13773552 ] 

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

Could be because the request handler (req_handler) runner is not stopped on stop(), just on a view change. I added method stop() in master, can you check out master and see if this works for you? The commit is 230766825a7db3d6806539fbe88210bdaa8509fa.

If not, can you describe how to reproduce this?

> 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.12.1#712002)