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

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

Hi Bela,

This is probably a big topic - do you know if JGroups has been tested with 
VMWare and the act of performing VMotions?

Do JGroups central locking and ping protocols "play well" when VMotions 
occur?

Were there any specific fixes made to JGroups to address issues with 
VMotions?

Thanks...

Dave


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