[JBoss JIRA] (ISPN-2604) When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2604?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2604:
-------------------------------------
Thinking some more about this, if you use expiry, the accuracy of your data is approximate anyway, so not sure this functionality is actually needed.
> When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2604
> URL: https://issues.jboss.org/browse/ISPN-2604
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Cache
> Reporter: Ray Tsang
> Assignee: Mircea Markus
>
> Following up on this topic, this is what I have setup:
> 2 nodes in cluster (either lib mode or remote) - node-1 and node-2
> a cache setup as distributed, synchronous (dist_sync)
> cache.put("key", "value", -1, TimeUnit.MILLISECONDS, 2000, TimeUnit.MILLISECONDS);
> for (i = 0; i < 10; i++) {
> sleep(1000) // sleep 1 second
> cache.get("key");
> }
> Here is the weird thing, after a few gets, I'm starting to get null results. This doesn't occur when there is only 1 node in the cluster.
> I'm suspecting that, w/ when accessing the data, it could be accessing 1 of the 2 nodes based on load balancing.
> cache.get("key") -> node-1 // 1s
> cache.get("key") -> node-1 // 2s
> cache.get("key") -> node-1 // 3s
> cache.get("key") -> node-2 // oops, this is already expired on node-2
> It would be nice to be able to make sure when accessing an entry from one node, the entry copies on other nodes are also "touched".
--
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, 3 months
[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-2697:
-----------------------------------
Bela: I was looking on this code and just wanted do be sure I understand it correctly. The code you posted causes one gossip to be sent in average every (desired_avg_gossip * clusterSize) milliseconds... I don't want to compute the exact mean delay of last gossip, but it's generally proportional to the cluster size = with big cluster, long time.
I suppose there aren't many messages in the replicated __hotrodTopologyCache as it is just filled from each node when it joins the cluster and then the values are not changed. So when the size-based stability does not kick in, the seqno-based one sends stability only every 5 minutes or more. I understand we want to save bandwidth, but this is really a long time, most timeouts are shorter than this (like some which expects some event after we bcast the message - not exactly the response).
Is this really desired behaviour?
> HotRodServer startup fails when its record cannot be inserted into topology cache
> ---------------------------------------------------------------------------------
>
> Key: ISPN-2697
> URL: https://issues.jboss.org/browse/ISPN-2697
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta6
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 5.2.0.CR2
>
>
> When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}).
> However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message.
--
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, 3 months
[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2609:
-------------------------------------
This means you try to put a key/value into the cache with value being null. This is something the cache doesn't support.
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Mircea Markus
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
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, 3 months
[JBoss JIRA] (ISPN-2609) Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2609?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-2609.
---------------------------------
Resolution: Rejected
> Infinispan SpringCache throws java.lang.NullPointerException: Null values are not supported!
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2609
> URL: https://issues.jboss.org/browse/ISPN-2609
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.1.6.FINAL
> Reporter: Roland Csupor
> Assignee: Mircea Markus
>
> I trying to use Infinispan as Spring cache, but if my function returns null, I got an exception, cause Spring tries to cache this result value:
> {noformat}
> Caused by: java.lang.NullPointerException: Null values are not supported!
> at org.infinispan.CacheImpl.assertKeyValueNotNull(CacheImpl.java:203) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:699) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheImpl.put(CacheImpl.java:694) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.CacheSupport.put(CacheSupport.java:53) ~[infinispan-core-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.infinispan.spring.provider.SpringCache.put(SpringCache.java:83) ~[infinispan-spring-5.1.6.FINAL.jar:5.1.6.FINAL]
> at org.springframework.cache.interceptor.CacheAspectSupport.update(CacheAspectSupport.java:390) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:218) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.2.RELEASE.jar:3.1.2.RELEASE]
> {noformat}
> Did I misconfigured something?
--
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, 3 months
[JBoss JIRA] (ISPN-2617) Intermittent failure of NodeMoveAPITest.testConcurrency
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2617?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2617:
--------------------------------
Fix Version/s: 5.3.0.Final
> Intermittent failure of NodeMoveAPITest.testConcurrency
> -------------------------------------------------------
>
> Key: ISPN-2617
> URL: https://issues.jboss.org/browse/ISPN-2617
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite, Tree API
> Affects Versions: 5.1.8.Final
> Reporter: Jitka Kudrnacova
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> The test NodeMoveAPITest.testConcurrency fails intermittently across platforms and JDKs.
> This is the output of TS on RHEL6_x86_64, Oracle JDK 6.
> Stacktrace:
> {code}
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> 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:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> 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:662)
> {code}
> Output:
> {code}
> 2012-12-05 10:21:34,463 FATAL [NodeMoveAPITest] (testng-NodeMoveAPITest) Tree:
> + / {}
> + b/ {}
> + x/ {}
> + a/ {}
> + e/ {}
> + c/ {}
> + x/ {}
> + y/ {}
> + d/ {}
> 2012-12-05 10:21:34,464 ERROR [UnitTestTestNGListener] (testng-NodeMoveAPITest) Method testConcurrency(org.infinispan.api.tree.NodeMoveAPITest) threw an exception
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> 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:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> 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:662)
> [testng-NodeMoveAPITest] Test testConcurrency(org.infinispan.api.tree.NodeMoveAPITest) failed.
> 2012-12-05 10:21:34,466 ERROR [UnitTestTestNGListener] (testng-NodeMoveAPITest) Test failed testConcurrency(org.infinispan.api.tree.NodeMoveAPITest)
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> 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:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> 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:662)
> {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
13 years, 3 months
[JBoss JIRA] (ISPN-2612) Problem broadcasting CH_UPDATE command
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2612?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2612:
--------------------------------
Fix Version/s: 5.2.0.CR2
> Problem broadcasting CH_UPDATE command
> --------------------------------------
>
> Key: ISPN-2612
> URL: https://issues.jboss.org/browse/ISPN-2612
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Fix For: 5.2.0.CR2
>
> Attachments: test.zip
>
>
> Infinispan 5.2.0.Beta5
> JGroups 3.2.4.Final
> Steps to reproduce (I'm using two virtual interfaces test1, test2)
> 1. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test1 -Djava.net.preferIPv4Stack=true
> 2. wait 10 sec
> 3. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test2 -Djava.net.preferIPv4Stack=true
> After 5 seconds there should be this timeout exception:
> {code}
> 19:42:14,146 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,mlinhard-work-37329) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___defaultcache, type=REBALANCE_CONFIRM, sender=mlinhard-work-47337, joinInfo=null, topologyId=1, currentCH=null, pendingCH=null, throwable=null, viewId=1}
> java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:563)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:349)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:213)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:160)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> 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:662)
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:152)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:518)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:545)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:542)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 3 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
> at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
> at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
> at org.jgroups.protocols.RSVP.down(RSVP.java:118)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:718)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
> at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:330)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:145)
> ... 8 more
> {code}
> Analysis:
> These are the messages sent after view change:
> {code}
> test1 test2
> <--- JOIN ----
> ---- REBALANCE_START --->
> <--- StateRequestCommand ----
> ---- StateResponseCommand --->
> <--- REBALANCE_CONFIRM ----
> ---- CH_UPDATE --->
> {code}
> The last CH_UPDATE message is broadcast, test2 successfully processes it, but test1 stays in waiting state, because it for some reason awaits response also from itself - local variable entry in the method RSVP.down
> (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> contained local address.
--
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, 3 months
[JBoss JIRA] (ISPN-2618) org.infinispan.distribution.rehash.L1OnRehashDisabledTest.testInvalidationBehaviorOnRehash randomly fails
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2618?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2618:
--------------------------------
Fix Version/s: 5.3.0.Final
> org.infinispan.distribution.rehash.L1OnRehashDisabledTest.testInvalidationBehaviorOnRehash randomly fails
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2618
> URL: https://issues.jboss.org/browse/ISPN-2618
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 5.3.0.Final
>
>
> The test is randomly failing on different environments.
> The error is:
> {code}
> Error Message
> Fail on non-owner cache L1OnRehashDisabledTest-NodeA-8972: dc.get(MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}) returned MortalCacheEntry{key=MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}, value=MortalCacheValue{value=v2, lifespan=600000, created=1355149157148}}!
> Stacktrace
> java.lang.AssertionError: Fail on non-owner cache L1OnRehashDisabledTest-NodeA-8972: dc.get(MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}) returned MortalCacheEntry{key=MagicKey#k2{18b213c7@L1OnRehashDisabledTest-NodeC-18200}, value=MortalCacheValue{value=v2, lifespan=600000, created=1355149157148}}!
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOwnershipAndNonOwnership(BaseDistFunctionalTest.java:212)
> at org.infinispan.distribution.rehash.L1OnRehashTest.testInvalidationBehaviorOnRehash(L1OnRehashTest.java:117)
> 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
13 years, 3 months