[JBoss JIRA] (ISPN-2477) AsyncStore shutdown can leak threads
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2477?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2477:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> AsyncStore shutdown can leak threads
> ------------------------------------
>
> Key: ISPN-2477
> URL: https://issues.jboss.org/browse/ISPN-2477
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.0.Beta3
> Reporter: Adrian Nistor
> Assignee: Galder Zamarreño
> Fix For: 5.2.1, 5.3.0.Final
>
>
> AsyncStore stop() should take care that all threads (coordinator and workers) are shut down. Right now there could be worker threads left hanging and the coordinator thread waiting forever for them to end.
> coordinator.join(shutdownTimeout) in AsyncStore.stop() could time out and both coordinator and worker thread will leak in this case.
> We must ensure the coordinator is terminated and the ExecutorService used for worker threads is also shut down when we exit AsyncStore.stop().
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2376:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes
> ----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2376
> URL: https://issues.jboss.org/browse/ISPN-2376
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.2.0.Beta1
> Reporter: Scott Marlow
> Assignee: Dan Berindei
> Fix For: 5.2.1, 5.3.0.Final
>
>
> I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning).
> We have two nodes running in the AS cluster, node-0/web and node-1/web.
> In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output.
> {quote}
> KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web]
> .
> .
> .
> KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web
> {quote}
> We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero).
> Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}).
> I'm still collecting information and want to get a little more.
> Let me know if there is anything that you would like to see.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-2789:
---------------------------------------
[~amanukyan] nice! what was the problem?
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2789:
----------------------------------
Fix Version/s: 5.3.0.Alpha1
5.3.0.Final
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2418) CLONE - Cache restart doesn't work properly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2418?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2418:
--------------------------------
Fix Version/s: 5.3.0.Final
(was: 6.0.0.Final)
> CLONE - Cache restart doesn't work properly
> -------------------------------------------
>
> Key: ISPN-2418
> URL: https://issues.jboss.org/browse/ISPN-2418
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.7.Final, 5.2.0.Alpha3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: jdg6
> Fix For: 5.1.9.Final, 5.3.0.Final
>
>
> Copied from ISPN-2297:
> {quote}
> If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it.
> Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache.
> {quote}
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2789:
-------------------------------------
Hey guys, I've fixed this issue already. Just need to make a pull request.
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2798) Test name differs from test class name
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2798?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2798:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1640
> Test name differs from test class name
> --------------------------------------
>
> Key: ISPN-2798
> URL: https://issues.jboss.org/browse/ISPN-2798
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.2.1, 5.3.0.Alpha1
>
>
> The log from a recent test run on core contains these warnings.
> Some of them are actually superfluous because they refer to abstract classes. UnitTestTestNGListener should not print such a warning if the test class is abstract.
> {noformat}
> 2013-02-05 17:18:14,372 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name AsyncAPIAsyncReplTest for class AsyncAPITxAsyncReplTest
> 2013-02-05 17:18:14,373 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name AsyncAPISyncReplTest for class AsyncAPITxSyncReplTest
> 2013-02-05 17:18:14,376 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name SyncReplImplicitLockingTest for class SyncReplPessimisticLockingTest
> 2013-02-05 17:18:15,351 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name DldEagerLockingReplicationTest for class DldPessimisticLockingReplicationTest
> 2013-02-05 17:18:15,354 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name Command line test for class BaseDldPessimisticLockingTest
> 2013-02-05 17:18:15,355 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name DldEagerLockingDistributedTest for class DldPessimisticLockingDistributedTest
> 2013-02-05 17:18:19,641 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name TransactionReleaseWithAsync2ndPhaseRecoveryTest for class TransactionCleanupWithAsync2ndPhaseRecoveryTest
> 2013-02-05 17:18:19,930 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name ReplLockReorderingTest for class ReplicatedLockReorderingTest
> 2013-02-05 17:18:23,524 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name TransactionReleaseWithAsync2ndPhaseTest for class TransactionCleanupWithAsync2ndPhaseTest
> 2013-02-05 17:18:39,416 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name AsyncTest for class AsyncStoreEvictionTest
> 2013-02-05 17:18:39,472 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name RemovedEntryFoundAsyncStoreTest for class AsyncStoreFunctionalTest
> 2013-02-05 17:18:52,937 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name InitiatorCrasherBeforePrepareOptimisticTest for class InitiatorCrashOptimisticTest
> 2013-02-05 17:19:02,368 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name BasicSingleLockRepOptTest for class BasicSingleLockReplOptTest
> 2013-02-05 17:19:24,012 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name TopologyAwareConsistentHashFactoryTest for class TopologyAwareSyncConsistentHashFactoryTest
> 2013-02-05 17:19:34,681 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name AsyncAPISyncDistTest for class AsyncAPITxSyncDistTest
> 2013-02-05 17:19:35,098 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name AsyncAPIAsyncDistTest for class AsyncAPITxAsyncDistTest
> 2013-02-05 17:20:44,563 WARN [org.infinispan.test.fwk.UnitTestTestNGListener] (TestNG) Wrong test name TxAndAsyncOpsTest for class TxCacheAndAsyncOpsTest
> {noformat}
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2510) PrepareCommands should fail on nodes where the cache is not running
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2510?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2510:
--------------------------------
Fix Version/s: 5.2.1
> PrepareCommands should fail on nodes where the cache is not running
> -------------------------------------------------------------------
>
> Key: ISPN-2510
> URL: https://issues.jboss.org/browse/ISPN-2510
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, RPC
> Affects Versions: 5.2.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.1, 5.3.0.Final
>
>
> When the user stops a cache without stopping the cache manager on that node, subsequent PrepareCommands sent to that node will return a {{SuccessfulResponse}}.
> If that node used to the primary owner of the command's modified key, the originator will proceed with the transaction as if it had acquired a lock on that key. It is thus possible for multiple transactions to think they have acquired the key lock at the same time.
> On the other hand, in replicated caches is is quite possible that a cache is not running on all the cluster node and yet PrepareCommands are broadcasted to everyone in parallel. So the solution should not involve sending exceptions (which have huge stack traces), and the originator should be able to ignore failures responses from nodes that were not targeted in the first place.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2789:
-------------------------------------
[~sannegrinovero] [~galderz] care to comment on this one please?
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2537) LockCleanupStateTransferTest fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2537?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2537:
--------------------------------
Fix Version/s: 5.2.1
> LockCleanupStateTransferTest fails randomly
> -------------------------------------------
>
> Key: ISPN-2537
> URL: https://issues.jboss.org/browse/ISPN-2537
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Beta4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.1, 5.3.0.Final
>
>
> LockCleanupStateTransferTest assumes that once the tx is done on one remote node it's done on all of them (and on the originator as well).
> It sometimes fails with this stack trace:
> {noformat}
> java.lang.AssertionError: For cache 0 expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.infinispan.tx.LockCleanupStateTransferTest.testLockReleasedCorrectly(LockCleanupStateTransferTest.java:164)
> at org.infinispan.tx.LockCleanupStateTransferTest.testBelatedCommit(LockCleanupStateTransferTest.java:76)
> {noformat}
--
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
13 years, 2 months