[JBoss JIRA] (ISPN-2615) org.infinispan.lock.StaleLocksTransactionTest testNoModsRollback and testNoModsCommit randomly fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2615?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2615:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 885708|https://bugzilla.redhat.com/show_bug.cgi?id=885708] from NEW to ASSIGNED
> org.infinispan.lock.StaleLocksTransactionTest testNoModsRollback and testNoModsCommit randomly fails
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-2615
> URL: https://issues.jboss.org/browse/ISPN-2615
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Dan Berindei
> Labels: testsuite_stability
>
> The tests are randomly failing on different environments.
> You can find the failures here:
> {code}
> Error Message
> expected [true] but found [false]
> Stacktrace
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:142)
> at org.infinispan.test.AbstractCacheTest.assertNotLocked(AbstractCacheTest.java:139)
> at org.infinispan.lock.StaleLocksTransactionTest.doTest(StaleLocksTransactionTest.java:79)
> at org.infinispan.lock.StaleLocksTransactionTest.testNoModsRollback(StaleLocksTransactionTest.java:61)
> 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}
> {code}
> Error Message
> expected [true] but found [false]
> Stacktrace
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:142)
> at org.infinispan.test.AbstractCacheTest.assertNotLocked(AbstractCacheTest.java:139)
> at org.infinispan.lock.StaleLocksTransactionTest.doTest(StaleLocksTransactionTest.java:79)
> at org.infinispan.lock.StaleLocksTransactionTest.testNoModsRollback(StaleLocksTransactionTest.java:61)
> 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, 1 month
[JBoss JIRA] (ISPN-2622) Random failure in RpcManagerMBeanTest
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2622:
----------------------------------
Summary: Random failure in RpcManagerMBeanTest
Key: ISPN-2622
URL: https://issues.jboss.org/browse/ISPN-2622
Project: Infinispan
Issue Type: Bug
Components: RPC
Affects Versions: 5.2.0.Beta5
Reporter: Dan Berindei
Assignee: Mircea Markus
Priority: Minor
Fix For: 5.3.0.Final
The test records the replication counter in RpcManagerImpl at the start of the test and after a put operation, and asserts that it only changed by 1. Occasionally, the assertion fails:
{noformat}
java.lang.AssertionError: expected [1] but found [2]
at org.testng.Assert.fail(Assert.java:89)
at org.testng.Assert.failNotEquals(Assert.java:489)
at org.testng.Assert.assertEquals(Assert.java:118)
at org.testng.Assert.assertEquals(Assert.java:160)
at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:126)
{noformat}
This happens because replication counter is only incremented *after* a successful RPC. The test starts when the cluster is considered "formed", that is when all the nodes are included in the read CH on every node. But that doesn't mean that the RPCs pushing state have finished - a pushing node may still be waiting for a response and so it might increment its replication counter after the start of the test.
--
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, 1 month
[JBoss JIRA] (ISPN-2595) Consistent hash factory configuration is ignored
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2595?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2595:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated.
> Consistent hash factory configuration is ignored
> ------------------------------------------------
>
> Key: ISPN-2595
> URL: https://issues.jboss.org/browse/ISPN-2595
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> HashConfigurationBuilder.create() ignores the consistent hash configured by the user.
> Instead it always creates the HashConfiguration with a {{null}} consistent hash factory, which means one of DefaultConsistentHashFactory and TopologyAwareConsistentHashFactory is picked based on the transport properties.
--
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, 1 month
[JBoss JIRA] (ISPN-2620) A segment can end up in two different InboutTransferTasks
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2620?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2620:
-------------------------------
Attachment: cnolt.log.gz
Complete log attached.
> A segment can end up in two different InboutTransferTasks
> ---------------------------------------------------------
>
> Key: ISPN-2620
> URL: https://issues.jboss.org/browse/ISPN-2620
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta6
>
> Attachments: cnolt.log.gz
>
>
> ConcurrentNonOverlappingLeaveTest is de facto disabled because of RehashTestBase doesn't have the @Test annotation (see ISPN-2534).
> I tried to enable it, but rehash wouldn't finish because NodeA wouldn't confirm receiving segment 38 from NodeC (the initial cluster was [NodeA, NodeB, NodeC, NodeD]). I think this is because segment 38 appears in two InboundTransferTasks:
> {noformat}
> 17:12:37,211 TRACE (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Segments not received yet for cache dist: {NodeC-40582=[
> InboundTransferTask{segments=[38], finishedSegments=[], unfinishedSegments=[38], source=NodeC-40582, isCancelled=false, topologyId=7, timeout=240000, cacheName=dist},
> InboundTransferTask{segments=[38, 42, 43, 40, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], finishedSegments=[40], unfinishedSegments=[38, 42, 43, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], source=NodeC-40582, isCancelled=false, topologyId=9, timeout=240000, cacheName=dist}]}
> 17:12:37,211 DEBUG (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Applying new state for segment 38 of cache dist from node NodeC-40582: received 0 cache entries
> 17:12:37,211 TRACE (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Segments not received yet for cache dist: {NodeC-40582=[
> InboundTransferTask{segments=[38], finishedSegments=[], unfinishedSegments=[38], source=NodeC-40582, isCancelled=false, topologyId=7, timeout=240000, cacheName=dist},
> InboundTransferTask{segments=[38, 42, 43, 40, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], finishedSegments=[40, 57, 38], unfinishedSegments=[42, 43, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 56], source=NodeC-40582, isCancelled=false, topologyId=9, timeout=240000, cacheName=dist}]}
> {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
12 years, 1 month
[JBoss JIRA] (ISPN-2620) A segment can end up in two different InboutTransferTasks
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2620:
----------------------------------
Summary: A segment can end up in two different InboutTransferTasks
Key: ISPN-2620
URL: https://issues.jboss.org/browse/ISPN-2620
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta5
Reporter: Dan Berindei
Assignee: Adrian Nistor
Priority: Critical
Fix For: 5.2.0.Beta6
ConcurrentNonOverlappingLeaveTest is de facto disabled because of RehashTestBase doesn't have the @Test annotation (see ISPN-2534).
I tried to enable it, but rehash wouldn't finish because NodeA wouldn't confirm receiving segment 38 from NodeC (the initial cluster was [NodeA, NodeB, NodeC, NodeD]). I think this is because segment 38 appears in two InboundTransferTasks:
{noformat}
17:12:37,211 TRACE (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Segments not received yet for cache dist: {NodeC-40582=[
InboundTransferTask{segments=[38], finishedSegments=[], unfinishedSegments=[38], source=NodeC-40582, isCancelled=false, topologyId=7, timeout=240000, cacheName=dist},
InboundTransferTask{segments=[38, 42, 43, 40, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], finishedSegments=[40], unfinishedSegments=[38, 42, 43, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], source=NodeC-40582, isCancelled=false, topologyId=9, timeout=240000, cacheName=dist}]}
17:12:37,211 DEBUG (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Applying new state for segment 38 of cache dist from node NodeC-40582: received 0 cache entries
17:12:37,211 TRACE (OOB-5,ISPN,NodeA-49710:dist) [StateConsumerImpl] Segments not received yet for cache dist: {NodeC-40582=[
InboundTransferTask{segments=[38], finishedSegments=[], unfinishedSegments=[38], source=NodeC-40582, isCancelled=false, topologyId=7, timeout=240000, cacheName=dist},
InboundTransferTask{segments=[38, 42, 43, 40, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 57, 56], finishedSegments=[40, 57, 38], unfinishedSegments=[42, 43, 41, 51, 50, 49, 55, 54, 53, 52, 59, 58, 56], source=NodeC-40582, isCancelled=false, topologyId=9, timeout=240000, cacheName=dist}]}
{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
12 years, 1 month
[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-1583.
------------------------------------
Fix Version/s: (was: 5.2.0.Final)
(was: 5.2.0.CR1)
Resolution: Won't Fix
Not sure how crucial this is, particularly since Paul found a workaround.
Paul, if you wanna reopen, please attach a more concrete example.
> AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
> -------------------------------------------------------------------------------------
>
> Key: ISPN-1583
> URL: https://issues.jboss.org/browse/ISPN-1583
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.0.BETA5
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
>
> When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
> Take the following code:
> AdvancedCache<K, V> baseCache;
> AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
> public void clear() {
> // custom clear logic
> }
> };
> customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
> In the above statement, the flag is not applied.
> The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
> In the case of with(ClassLoader) we have the opposite problem.
> customCache.with(customClassLoader).clear();
> In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of customCache.
--
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, 1 month
[JBoss JIRA] (ISPN-2580) Do not request segments from all nodes at once
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2580?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-2580:
------------------------------
Priority: Critical (was: Major)
> Do not request segments from all nodes at once
> ----------------------------------------------
>
> Key: ISPN-2580
> URL: https://issues.jboss.org/browse/ISPN-2580
> Project: Infinispan
> Issue Type: Enhancement
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta6
>
>
> When a new node joins large cluster filled with data, it gets the new CH and REBALANCE_START command, and requests data from all nodes at once (or almost all with even distribution of segments). It may be not able to handle this amount of transfers in parallel even at the JGroups level - this results in data sent to the node and discarded at the receiver, sent again and again. With a heavy congestion the node just buffers fragments of a message from one sender and never passes this up.
> The number of StateRequestCommands(START_STATE_TRANSFER) should be limited so that the node is not congested.
--
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, 1 month
[JBoss JIRA] (ISPN-2553) JBossMarshaller can be used before properly initialized
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2553?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2553:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1521
> JBossMarshaller can be used before properly initialized
> -------------------------------------------------------
>
> Key: ISPN-2553
> URL: https://issues.jboss.org/browse/ISPN-2553
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.2.0.Beta4
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.Beta6
>
>
> The {{JBossMarshaller}} can be used before its {{start()}} method is called. I've noticed that with replicated cache without transactions, an OOB thread can start demarshalling {{SingleRpcCommand}} in {{CacheRpcCommandExternalizer}} but when it tries to create a new unmarshaller (through {{AbstractJBossMarshaller.startObjectInput(...)}} and the {{marshallerTL.initialValue()}} the {{baseCfg}} configuration is not fully initialized yet and this results in creating marshallers in {{PerThreadInstanceHolder}} with {{objectTable == null}}. Then, objects are deserialized to {{null}}.
> I have verified this by inserting some log messages into constructors and start method:
> {code}
> 19:49:02,404 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating AbstractJBossMarshaller with org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternalizerFactor
> y=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> 19:49:02,409 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating JBossMarshaller org.infinispan.marshall.jboss.JBossMarshaller@2e3e4d73
> 19:49:02,410 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Starting JBossMarshaller
> {code}
> and into the thread-local initialization and to {{getUnmarshaller()}} just before {{factory.createUnmarshaller}}:
> {code}
> 19:49:02,410 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) No object table in org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infinisp
> an.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3, base is org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternali
> zerFactory=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> 19:49:02,453 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) Unmarshaller with cfg org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infin
> ispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> {code}
> See that the timestamps for {{start()}} and thread-local initialization are same, and the base configuration ({{baseCfg}}) does not have {{objectTable}} initialized.
--
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, 1 month