ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Magda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology
Date Wed, 29 Jun 2016 12:09:37 GMT

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

Denis Magda commented on IGNITE-3386:


This is definitely the bug because {{lock.await}} mustn't hang if the node that stored the
lock left topology and there are no backups left. In this scenario after the exception that
is in the description occurs the node, where it's happened and which tries to acquire the
lock, silently hanging at  {{lock.await}} method.

> 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: LockIssue.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

View raw message