[
https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin....
]
Dan Berindei edited comment on ISPN-4504 at 7/16/14 5:06 AM:
-------------------------------------------------------------
I got some failures in {{StateTransferLargeObjectTest}} because
{{ClusteredGetCommand.canBlock()}} was returning {{false}}, but it was blocking the OOB
thread to wait for a new topology.
That was easy to fix, but it made me wonder if we really need {{ClusteredGetCommand}} to
block. So I changed it to no longer implement {{TopologyAwareCommand}} and I re-enabled
scenarios 5 and 7, and everything seems to work fine.
was (Author: dan.berindei):
I got some failures in {{StateTransferLargeObjectTest}} because
{{ClusteredGetCommand.canBlock()}} was returning {{false}}, but it was blocking the OOB
thread to wait for a new topology.
That was easy to fix, but it made me wonder if we really need {{ClusteredGetCommand}}s to
block. So I changed it to no longer implement {{TopologyAwareCommand}} and I re-enabled
scenarios 5 and 7, and everything seems to work fine.
Topology id is not properly set on ClusteredGetCommands
-------------------------------------------------------
Key: ISPN-4504
URL:
https://issues.jboss.org/browse/ISPN-4504
Project: Infinispan
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Core
Affects Versions: 7.0.0.Alpha4
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Alpha5
Because the topology id is not properly set on ClusteredGetCommands, they don't wait
for the sender's topology to be installed on the target.
I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2
failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
| sc | currentTopologyId | currentTopologyId + 1 (rebalance) |
currentTopologyId + 2 (finish) |
| 5 | 0:remoteGet | 2:sendReply |
0:receiveReply, 1:sendReply |
| 7 | | 0:remoteGet, 2: sendReply |
0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)