ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Tupitsyn (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology
Date Tue, 09 Aug 2016 12:32:26 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Pavel Tupitsyn updated IGNITE-3386:
-----------------------------------
    Fix Version/s:     (was: 1.7)
                   1.8

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

Mime
View raw message