[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-3942:
-----------------------------------
[~dan.berindei], Radim has a point. Note that this is another problem...
In the client, the first attempt is performed in the owner (or primary owner, not sure) of the key, let's say server A. If A is down, the next attempt will use the RequestBalancingStrategy. However, this strategy can return the same server again. Why? because we didn't contact any live server so we don't have an updated list.
Eventually, it will hit a live server and will get the updated list. In the meanwhile, the fix will avoid an extra wait.
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
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-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3942:
------------------------------------
[~rvansa] as I understand it, the main problem was actually on the server side. Because of ISPN-3845, the addresses of the failed servers were not properly removed from the address cache, and the server would send the topology update to the client with the new topology but with the old list of members. [~pruivo] can you comment on that?
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
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-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3942:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2377, https://github.com/infinispan/infinispan/pull/2369, https://github.com/infinispan/infinispan/pull/2370 (was: https://github.com/infinispan/infinispan/pull/2377)
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
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-3985) In BCHM traverse internal segments for parallel map/reduce execution
by Vladimir Blagojevic (JIRA)
Vladimir Blagojevic created ISPN-3985:
-----------------------------------------
Summary: In BCHM traverse internal segments for parallel map/reduce execution
Key: ISPN-3985
URL: https://issues.jboss.org/browse/ISPN-3985
Project: Infinispan
Issue Type: Enhancement
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Priority: Minor
Currently when BoundedConcurrentHashMap is used in DataContainer we split input keys and traverse key/value pairs in parallel using executor. That is all good, however, we should optimize this solution as each segment in BCHM is a separate map we can iterate over each segment in a separate thread rather than blindly splitting input keys.
--
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-2910) Divide by zero exception on shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2910:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 920079|https://bugzilla.redhat.com/show_bug.cgi?id=920079] from NEW to ON_QA
> Divide by zero exception on shutdown
> ------------------------------------
>
> Key: ISPN-2910
> URL: https://issues.jboss.org/browse/ISPN-2910
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Labels: nbst
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web]
> 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
--
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-2589) NPE in InvalidateL1Command
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2589?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2589:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 916988|https://bugzilla.redhat.com/show_bug.cgi?id=916988] from NEW to ON_QA
> NPE in InvalidateL1Command
> --------------------------
>
> Key: ISPN-2589
> URL: https://issues.jboss.org/browse/ISPN-2589
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 5.2.0.Beta5, 5.2.7.Final
> Reporter: Thomas Fromm
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
> Attachments: standalone_node0001.xml
>
>
> The used cache is an REPL_SYNC one w/o L1 and Optimistic TX.
> Can't provide unit test, just saw it in my logs.
> WARN 05.12.12 20:08:22,746 [OOB-173,IBIS-2147] CacheTopologyControlCommand ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MODULE_PROPERTIES_VERSION, type=CH_UPDATE, sender=IBIS-57850, joinInfo=null, topologyId=14, currentCH=ReplicatedConsistentHash{members=[IBIS-57850, IBIS-15651, IBIS-14611, IBIS-7942, IBIS-4256, IBIS-25472, IBIS-32523]}, pendingCH=null, throwable=null, viewId=8}
> java.lang.NullPointerException
> at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
> at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:110)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitInvalidateCommand(CacheLoaderInterceptor.java:127)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:256)
> at org.infinispan.interceptors.TxInterceptor.visitInvalidateCommand(TxInterceptor.java:224)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:172)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:592)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:239)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:117)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> 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.FC.up(FC.java:479)
> 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.up(UNICAST2.java:432)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
> 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.MERGE3.up(MERGE3.java:290)
> 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.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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-3982) TransactionTable leaks memory when JTS is activated
by Andrey Smirnov (JIRA)
[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ]
Andrey Smirnov updated ISPN-3982:
---------------------------------
Attachment: 0001-ISPN-3982-fixed.patch.gz
Attached patch fixed mem-leak for me
> TransactionTable leaks memory when JTS is activated
> ---------------------------------------------------
>
> Key: ISPN-3982
> URL: https://issues.jboss.org/browse/ISPN-3982
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.7.Final
> Reporter: Andrey Smirnov
> Assignee: Dan Berindei
> Fix For: 5.2.8.Final
>
> Attachments: 0001-ISPN-3982-fixed.patch.gz
>
>
> JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour.
> This causes mem-leak in TransactionTable when activating JTS.
--
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-3984) CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3984:
----------------------------------
Summary: CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
Key: ISPN-3984
URL: https://issues.jboss.org/browse/ISPN-3984
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 6.0.1.Final
Reporter: Dan Berindei
Assignee: Vladimir Blagojevic
Fix For: 7.0.0.Alpha1
Attachments: cmdtnmrt.log.gz
The random failures in CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys seem to be caused by state transfer being disabled in the test's caches.
{noformat}
12:11:51,674 ERROR (testng-CompatModeDistributedTwoNodesMapReduceTest:) [UnitTestTestNGListener] Test testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.CompatModeDistributedTwoNodesMapReduceTest) failed.
java.lang.AssertionError: key 'well' does not have count 1 but 2
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:224)
at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:334)
at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseWordCountMapReduceTest.java:162)
{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-3984) CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3984?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3984:
-------------------------------
Attachment: cmdtnmrt.log.gz
> CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3984
> URL: https://issues.jboss.org/browse/ISPN-3984
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha1
>
> Attachments: cmdtnmrt.log.gz
>
>
> The random failures in CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys seem to be caused by state transfer being disabled in the test's caches.
> {noformat}
> 12:11:51,674 ERROR (testng-CompatModeDistributedTwoNodesMapReduceTest:) [UnitTestTestNGListener] Test testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.CompatModeDistributedTwoNodesMapReduceTest) failed.
> java.lang.AssertionError: key 'well' does not have count 1 but 2
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:224)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:334)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseWordCountMapReduceTest.java:162)
> {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