[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2013:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> 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: Pedro Ruivo
> Fix For: 6.0.0.Beta1, 6.0.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
12 years, 7 months
[JBoss JIRA] (ISPN-2895) org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2895?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2895:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile fails randomly
> --------------------------------------------------------------------------------
>
> Key: ISPN-2895
> URL: https://issues.jboss.org/browse/ISPN-2895
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.2.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Labels: stable_embedded_query, testsuite_stability
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> The test fails randomly and the error message is:
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:76)
> at org.infinispan.lucene.DirectoryIntegrityCheck.verifyDirectoryStructure(DirectoryIntegrityCheck.java:56)
> at org.infinispan.lucene.InfinispanDirectoryIOTest.verifyOnBuffer(InfinispanDirectoryIOTest.java:184)
> at org.infinispan.lucene.InfinispanDirectoryIOTest.testReadWholeFile(InfinispanDirectoryIOTest.java:153)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-2780) org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2780?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2780:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2780
> URL: https://issues.jboss.org/browse/ISPN-2780
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.CR3
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Labels: stable_embedded_query
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> The test org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails almost always on all environments. The error message is:
> {code}
> Error Message
> String '0' should exist but was not found in index
> Stacktrace
> java.lang.AssertionError: String '0' should exist but was not found in index
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyOnDirectory(IndexCacheLoaderTest.java:131)
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyIndex(IndexCacheLoaderTest.java:83)
> at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest(IndexCacheLoaderTest.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-2709) Lib dir in distribution archive does not contain the proper versions for some dependencies
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2709?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2709:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> Lib dir in distribution archive does not contain the proper versions for some dependencies
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2709
> URL: https://issues.jboss.org/browse/ISPN-2709
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.CR1
> Reporter: Adrian Nistor
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
> Attachments: actual.txt, should_be.txt
>
>
> Not all the jars referenced by runtime-classpath.txt files of modules are actually present in the lib dir. In some cases the jar is present but not the needed version. Some of the jars are there but are not actually used.
> It all happens because the set of dependencies for runtime-classpath.txt is computed for each individual module while the lib dir in the distro is created by assembly plugin after 'merging' the dependencies of all modules which means that only the highest version will be included. Also, maven dependency plugin is known to miss some dependencies.
> To avoid the version problem we could define globally a single version for each of these dependencies in parent pom dependencyManagement and also explicitly add the dependency in the respective modules.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-2702) RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2702?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2702:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly
> ----------------------------------------------------------------------------
>
> Key: ISPN-2702
> URL: https://issues.jboss.org/browse/ISPN-2702
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
> Attachments: RecoveryWithCustomCacheDistTest.log.gz, testNodeCrashesAfterPrepare-1.log
>
>
> {code}testNodeCrashesAfterPrepare(org.infinispan.tx.recovery.RecoveryWithCustomCacheDistTest) Time elapsed: 0.083 sec <<< FAILURE!
> java.lang.RuntimeException: javax.transaction.xa.XAException
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:58)
> at org.infinispan.tx.recovery.RecoveryWithDefaultCacheDistTest.testNodeCrashesAfterPrepare(RecoveryWithDefaultCacheDistTest.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:110)
> at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:56)
> ... 22 more{code}
--
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
12 years, 7 months