2 Replies Latest reply: Apr 25, 2012 1:48 PM by Dmitry Udalov RSS

    Using explicit "unlock" causes TimeoutException for some other Threads

    Dmitry Udalov Newbie

      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)

       

       

      Is it a known issue or it's unsupported pattern?

       

      Thanks,

      Dmitry