[jira] [Commented] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology

["Denis Magda (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405038#comment-15405038 ] 

Denis Magda commented on IGNITE-3386:
-------------------------------------

Vladislav,

I was wrong, there is no hanging happens when the exception, discussed in the ticket, is thrown. I've improved the test (LockIssueVer2.java) and now the exception is 100% reproducible.  In my understanding we should catch this exception internally and re-create the lock from scratch if {{create=true}} flag is set to {{true}}. What do you think?

> Reentrant lock is lost when lock owner leaves topology
> ------------------------------------------------------
>
>                 Key: IGNITE-3386
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3386
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 1.6
>            Reporter: Denis Magda
>            Assignee: Vladisav Jelisavcic
>            Priority: Critical
>              Labels: important
>             Fix For: 1.7
>
>         Attachments: LockIssueVer2.java
>
>
> If to create a lock with the following configuration 
> {{IgniteLock lock = ignite.reentrantLock("lock", true, true, true);}}
> and perform the following steps below
> 1) run the first node using {{LockIssue}} that is attached;
> 2) run the second node using {{LockIssue}};
> 3) stop the first node.
> you will get the following exception on the second node side (the lock information will be lost and the second node won't recreate it ignore "create=true" flag):
> {code}
> SEVERE: <ignite-atomics-sys-cache> Failed to compare and set: o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync$1@67aea87d
> class org.apache.ignite.IgniteCheckedException: Failed to find reentrant lock with given name: test
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:525)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:518)
>   at org.apache.ignite.internal.processors.cache.GridCacheUtils$23.call(GridCacheUtils.java:1648)
>   at org.apache.ignite.internal.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:891)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.compareAndSetGlobalState(GridCacheLockImpl.java:517)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:400)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:437)
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:861)
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.lock(GridCacheLockImpl.java:432)
>   at org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1201)
>   at com.bfm.amc.loaders.server.StartIgniteServer.main(StartIgniteServer.java:15)
> {code}
> However the issue is not 100% reproduced but it should be clear from the logs what happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)