[infinispan-issues] [JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads

[Galder Zamarreño (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreño updated ISPN-2013:
-----------------------------------

    Assignee: Mircea Markus  (was: Manik Surtani)

    
> Using explicit "unlock" causes TimeoutException for other Threads
> -----------------------------------------------------------------
>
>                 Key: ISPN-2013
>                 URL: https://issues.jboss.org/browse/ISPN-2013
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 5.1.2.FINAL
>         Environment: Windows 7 64-bit
>            Reporter: Dmitry Udalov
>            Assignee: Mircea Markus
>             Fix For: 5.2.0.Final
>
>         Attachments: LockTest.java
>
>
> In a test I have several tasks that run on a single cache node configured as transactional pessimistic replicated cache. If I explicitly call "unlock" then I consistently see TimeoutException reported by some tasks. Without explicit "unlock" the test works fine. Does it mean that I should never call "unlock" and rely on transaction.commit/rollback ? It's seen with infinispan-5.1.2.FINAL
>  
> Here's what in a nutshell each task does:
>  
> final lockKey = ...
>  
> executor.submit(new Callable<Boolean>()   {
>    public Boolean call() throws Exception
>  
>       TransactionManager tx = cache.getAdvancedCache().getTransactionManager(); 
>       tx.begin()
>       try {
>           if ( lockManager.lock(lockKey) ) {
>  
>              // ...
>          
>              // removing next line makes test happy. Otherwise some tasks report TimeoutException (pls. see the stack traces)
>              cache.getLockManager().unlock(lockKey);      
>           }
>       }   catch(Throwable t) {
>           tx.setRollbackOnly();
>       }  finally {
>           if (ut.getStatus() == Status.STATUS_ACTIVE)
>               ut.commit();
>           else
>              ut.rollback();
>       }
>  
>  
> By the time I received that exception all other tasks were completed and they released the lock on the key in question.
> I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread - see "Lock held by [null]", which seems to be right. But yet the lock failed to be acquired.
> Is it a matter to trying it one more time?
>  
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock held by [null]
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206)
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180)
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170)
>     at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
>     at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
>     at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>     at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>     at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>     at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207)
>     at org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>     at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
>     at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94)
>     at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>     at org.infinispan.CacheImpl.lock(CacheImpl.java:484)
>     at org.infinispan.CacheImpl.lock(CacheImpl.java:468)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira