[JBoss JIRA] (ISPN-6680) InterruptedException during PutAll from Hot Rod client prevents failover
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6680?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6680:
------------------------------------
Also causes random failures in DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges:
http://ci.infinispan.org/viewLog.html?buildId=40113&buildTypeId=bt9&guest=1
> InterruptedException during PutAll from Hot Rod client prevents failover
> ------------------------------------------------------------------------
>
> Key: ISPN-6680
> URL: https://issues.jboss.org/browse/ISPN-6680
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha2
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.Alpha3
>
>
> The server throws an InterruptedException during the PutAllCommand:
> {noformat}
> 2016-05-19 10:28:06,407 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRodServerHandler-4-22) ISPN000136: Error executing command PutMapCommand, writing keys [[B0x034b0000005a, [B0x034b0000005d, [B0x034b0000005b, [B0x034b0000005c, [B0x034b0000005e]: java.lang.InterruptedException
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:347)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1907)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutMapCommand(NonTxDistributionInterceptor.java:201)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutMapCommand(NonTxDistributionInterceptor.java:67)
> at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:68)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.doInvokeNextSync(BaseSequentialInvocationContext.java:265)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.forkInvocationSync(BaseSequentialInvocationContext.java:90)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:515)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForPutMapCommand(EntryWrappingInterceptor.java:563)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutMapCommand(EntryWrappingInterceptor.java:311)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutMapCommand(EntryWrappingInterceptor.java:77)
> at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:68)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.doInvokeNextSync(BaseSequentialInvocationContext.java:265)
> {noformat}
> That gets propagated to the client that does not recover from the error:
> {noformat}
> org.infinispan.client.hotrod.exceptions.ParallelOperationException:: java.util.concurrent.ExecutionException: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=218 returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.InterruptedException
> java.lang.InterruptedException
> at org.infinispan.client.hotrod.impl.operations.ParallelHotRodOperation.executeParallel(ParallelHotRodOperation.java:79)
> at org.infinispan.client.hotrod.impl.operations.ParallelHotRodOperation.execute(ParallelHotRodOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putAll(RemoteCacheImpl.java:223)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.putAll(RemoteCacheSupport.java:49)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6422) ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6422?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6422:
------------------------------------
Still fails rather often: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=-89...
> ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-6422
> URL: https://issues.jboss.org/browse/ISPN-6422
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Adrian Nistor
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Alpha3
>
>
> http://ci.infinispan.org/viewLog.html?buildId=37676&tab=buildResultsDiv&b...
> {code}
> java.lang.NullPointerException: null
> at java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:185)
> at java.util.Arrays.sort(Arrays.java:1312)
> at java.util.Arrays.sort(Arrays.java:1506)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:141)
> at org.infinispan.server.eventlogger.ServerEventLogger.getEvents(ServerEventLogger.java:131)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest$2.call(ServerEventLoggerTest.java:86)
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1348)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest.testClusteredServerEventLogging(ServerEventLoggerTest.java:66)
> ------- Stdout: -------
> Configuring TestNG with: TestNG652Configurator
> Transport protocol stack used = tcp
> ------- Stderr: -------
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|0] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeA-31008, physical addresses are [127.0.0.1:7900]
> Mar 20, 2016 2:14:51 AM org.infinispan.factories.GlobalComponentRegistry start
> INFO: ISPN000128: Infinispan version: Infinispan 'Chakra' 9.0.0-SNAPSHOT
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeB-14491, physical addresses are [127.0.0.1:7901]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeC-47842, physical addresses are [127.0.0.1:7902]
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #1
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #2
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #3
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #4
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #5
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #6
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #7
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #8
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #9
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #10
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #11
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #12
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|4] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6751) Backports for 8.1.5.Final
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-6751:
----------------------------------
Summary: Backports for 8.1.5.Final
Key: ISPN-6751
URL: https://issues.jboss.org/browse/ISPN-6751
Project: Infinispan
Issue Type: Task
Components: Core
Affects Versions: 8.1.4.Final
Reporter: Paul Ferraro
Fix For: 8.1.5.Final
Tracking jira.for issues to be backported to 8.1.5.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6740) Client topologies not updated when cache topology loaded from persistent state
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6740?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6740:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.3.Final
Resolution: Done
> Client topologies not updated when cache topology loaded from persistent state
> ------------------------------------------------------------------------------
>
> Key: ISPN-6740
> URL: https://issues.jboss.org/browse/ISPN-6740
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, State Transfer
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Reporter: Galder Zamarreño
> Assignee: Dan Berindei
> Fix For: 9.0.0.Alpha3, 9.0.0.Final, 8.2.3.Final
>
>
> Infinispan Caches now support storing persistent views. When these are loaded, these might be loaded with topology ID 0:
> {code}
> 2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl] (MSC service thread 1-3)
> ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT timestamp=2016-05-30T12:03:33.822Z
> ....
> 2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-6)
> Installing new cache topology CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
> pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6], persistentUUIDs=[
> bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache default
> {code}
> If there's no further view changes, the topology ID will remain 0. When a Hot Rod client first connects, it sends its view topology as 0 so that it receives a newly installed topology, but if the topology is already 0 in the server, the server won't send the installed topology, even though it should be newer than having no topology.
> We should start numbering topologies in server starting from 1 instead. That avoids this issue. This is easier than forcing clients to send -1 as initial topology because the topology ID is currently defined as VInt that can only 0 or positive number.
> Also, some extra log messages indicating that the cache topology installed comes from persisted state would be handy for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6750) Client topologies not updated when cache topology loaded from persistent state
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6750:
----------------------------------
Summary: Client topologies not updated when cache topology loaded from persistent state
Key: ISPN-6750
URL: https://issues.jboss.org/browse/ISPN-6750
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, State Transfer
Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
Reporter: Galder Zamarreño
Assignee: Dan Berindei
Fix For: 9.0.0.Alpha3, 9.0.0.Final
Infinispan Caches now support storing persistent views. When these are loaded, these might be loaded with topology ID 0:
{code}
2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl] (MSC service thread 1-3)
ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT timestamp=2016-05-30T12:03:33.822Z
....
2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-6)
Installing new cache topology CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6], persistentUUIDs=[
bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache default
{code}
If there's no further view changes, the topology ID will remain 0. When a Hot Rod client first connects, it sends its view topology as 0 so that it receives a newly installed topology, but if the topology is already 0 in the server, the server won't send the installed topology, even though it should be newer than having no topology.
We should start numbering topologies in server starting from 1 instead. That avoids this issue. This is easier than forcing clients to send -1 as initial topology because the topology ID is currently defined as VInt that can only 0 or positive number.
Also, some extra log messages indicating that the cache topology installed comes from persisted state would be handy for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6749) Disable SiteProviderTopologyChangeTest.testXSiteSTDuringSiteMasterLeave
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6749?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6749:
------------------------------------
[~pruivo] I'm not sure what you mean by "It requires some UNICAST/NAKACK between sites", the {{bridge.xml}} configuration used for the bridge channel in the test suite has both {{UNICAST3}} and {{NAKACK2}}.
Also, why would this affect only state push and not regular cross-site replication?
> Disable SiteProviderTopologyChangeTest.testXSiteSTDuringSiteMasterLeave
> -----------------------------------------------------------------------
>
> Key: ISPN-6749
> URL: https://issues.jboss.org/browse/ISPN-6749
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 9.0.0.Alpha3
>
>
> Two sites: LON(nodes A,B,C) and NYC(nodes D,E,F). Node A and D are the site master of LON and NYC respectively.
> Site LON is going to push state to site NYC. The push state request is done in node B and the request is done when node A is leaving the cluster. In order to push the state, it sends a START_RECEIVE to NYC site.
> {noformat}
> About to send to backups [NYC (sync, timeout=2000)], command XSiteStateTransferControlCommand{control=START_RECEIVE, siteName='null', statusOk=false, cacheName='___defaultcache'}
> SiteProviderTopologyChangeTest-NodeB-48243: invoking unicast RPC [req-id=98] on SiteMaster(NYC)
> SiteProviderTopologyChangeTest-NodeB-48243: forwarding message to final destination SiteMaster(NYC) to the current coordinator
> SiteProviderTopologyChangeTest-NodeB-48243: sending msg to SiteProviderTopologyChangeTest-NodeA-41240, src=SiteProviderTopologyChangeTest-NodeB-48243, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=32, TP: [cluster_name=ISPN(SITE LON)]
> {noformat}
> The message is forward to node A (site master LON) that sends it to node D (site master NYC)
> {noformat}
> SiteProviderTopologyChangeTest-NodeA-41240: received [dst: SiteProviderTopologyChangeTest-NodeA-41240, src: SiteProviderTopologyChangeTest-NodeB-48243 (4 headers), size=29 bytes, flags=OOB|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=32, TP: [cluster_name=ISPN(SITE LON)]
> _SiteProviderTopologyChangeTest-NodeA-41240:LON: sending msg to _SiteProviderTopologyChangeTest-NodeD-50088:NYC, src=_SiteProviderTopologyChangeTest-NodeA-41240:LON, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=2, conn_id=1, TP: [cluster_name=global]
> {noformat}
> Response is sent back from node D to node A that forwards it to node B.
> {noformat}
> _SiteProviderTopologyChangeTest-NodeA-41240:LON: received [dst: _SiteProviderTopologyChangeTest-NodeA-41240:LON, src: _SiteProviderTopologyChangeTest-NodeD-50088:NYC (4 headers), size=4 bytes, flags=OOB|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteProviderTopologyChangeTest-NodeB-48243:LON, sender=SiteMaster(NYC)], UNICAST3: DATA, seqno=3, TP: [cluster_name=global]
> SiteProviderTopologyChangeTest-NodeA-41240: sending msg to SiteProviderTopologyChangeTest-NodeB-48243, src=SiteProviderTopologyChangeTest-NodeA-41240, headers are RequestCorrelator: corr_id=200, type=RSP, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteProviderTopologyChangeTest-NodeB-48243:LON, sender=SiteMaster(NYC)], UNICAST3: DATA, seqno=30, conn_id=1, TP: [cluster_name=ISPN(SITE LON)]
> {noformat}
> However, since node A is shutting-down, the response never arrives to node B that ends up throwing TimeoutException.
> {noformat}
> SiteProviderTopologyChangeTest-NodeA-41240: sending 1 msgs (218 bytes (0.70% of max_bundle_size) to 1 dests(s): [ISPN(SITE LON):SiteProviderTopologyChangeTest-NodeB-48243]
> 127.0.0.1:7900: server is not running, discarding message to 127.0.0.1:7901
> {noformat}
> The test will be disabled because:
> * This push state is triggered manually and it can be re-triggered in case of exceptions
> * It requires some UNICAST/NAKACK between sites (i.e. changing jgroups)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (ISPN-6749) Disable SiteProviderTopologyChangeTest.testXSiteSTDuringSiteMasterLeave
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6749?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6749:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Disable SiteProviderTopologyChangeTest.testXSiteSTDuringSiteMasterLeave
> -----------------------------------------------------------------------
>
> Key: ISPN-6749
> URL: https://issues.jboss.org/browse/ISPN-6749
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 9.0.0.Alpha3
>
>
> Two sites: LON(nodes A,B,C) and NYC(nodes D,E,F). Node A and D are the site master of LON and NYC respectively.
> Site LON is going to push state to site NYC. The push state request is done in node B and the request is done when node A is leaving the cluster. In order to push the state, it sends a START_RECEIVE to NYC site.
> {noformat}
> About to send to backups [NYC (sync, timeout=2000)], command XSiteStateTransferControlCommand{control=START_RECEIVE, siteName='null', statusOk=false, cacheName='___defaultcache'}
> SiteProviderTopologyChangeTest-NodeB-48243: invoking unicast RPC [req-id=98] on SiteMaster(NYC)
> SiteProviderTopologyChangeTest-NodeB-48243: forwarding message to final destination SiteMaster(NYC) to the current coordinator
> SiteProviderTopologyChangeTest-NodeB-48243: sending msg to SiteProviderTopologyChangeTest-NodeA-41240, src=SiteProviderTopologyChangeTest-NodeB-48243, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=32, TP: [cluster_name=ISPN(SITE LON)]
> {noformat}
> The message is forward to node A (site master LON) that sends it to node D (site master NYC)
> {noformat}
> SiteProviderTopologyChangeTest-NodeA-41240: received [dst: SiteProviderTopologyChangeTest-NodeA-41240, src: SiteProviderTopologyChangeTest-NodeB-48243 (4 headers), size=29 bytes, flags=OOB|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=32, TP: [cluster_name=ISPN(SITE LON)]
> _SiteProviderTopologyChangeTest-NodeA-41240:LON: sending msg to _SiteProviderTopologyChangeTest-NodeD-50088:NYC, src=_SiteProviderTopologyChangeTest-NodeA-41240:LON, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteMaster(NYC), sender=SiteProviderTopologyChangeTest-NodeB-48243:LON], UNICAST3: DATA, seqno=2, conn_id=1, TP: [cluster_name=global]
> {noformat}
> Response is sent back from node D to node A that forwards it to node B.
> {noformat}
> _SiteProviderTopologyChangeTest-NodeA-41240:LON: received [dst: _SiteProviderTopologyChangeTest-NodeA-41240:LON, src: _SiteProviderTopologyChangeTest-NodeD-50088:NYC (4 headers), size=4 bytes, flags=OOB|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteProviderTopologyChangeTest-NodeB-48243:LON, sender=SiteMaster(NYC)], UNICAST3: DATA, seqno=3, TP: [cluster_name=global]
> SiteProviderTopologyChangeTest-NodeA-41240: sending msg to SiteProviderTopologyChangeTest-NodeB-48243, src=SiteProviderTopologyChangeTest-NodeA-41240, headers are RequestCorrelator: corr_id=200, type=RSP, req_id=98, rsp_expected=true, RELAY2: DATA [dest=SiteProviderTopologyChangeTest-NodeB-48243:LON, sender=SiteMaster(NYC)], UNICAST3: DATA, seqno=30, conn_id=1, TP: [cluster_name=ISPN(SITE LON)]
> {noformat}
> However, since node A is shutting-down, the response never arrives to node B that ends up throwing TimeoutException.
> {noformat}
> SiteProviderTopologyChangeTest-NodeA-41240: sending 1 msgs (218 bytes (0.70% of max_bundle_size) to 1 dests(s): [ISPN(SITE LON):SiteProviderTopologyChangeTest-NodeB-48243]
> 127.0.0.1:7900: server is not running, discarding message to 127.0.0.1:7901
> {noformat}
> The test will be disabled because:
> * This push state is triggered manually and it can be re-triggered in case of exceptions
> * It requires some UNICAST/NAKACK between sites (i.e. changing jgroups)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months