[
https://issues.jboss.org/browse/ISPN-4549?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-4549:
----------------------------------------
Dan, I'm not sure I understand your assessment, possibly due to lack of knowledge of
state transfer. The coordinator only starts rebalance once rebalancing is enabled. I mean,
yes, once the coordinator's rebalance flag is disabled and the 3rd node is stopped, it
waits for the coordinator to not be in a rebalancing mode, and then it checks the number
of entries. TBH, I'm not sure it should be checking for these number of entries, it
feels to me these checks are a bit too brittle? In any case, this is probably something
that you should address since you're the state transfer expert? :)
StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures
----------------------------------------------------------------------------------
Key: ISPN-4549
URL:
https://issues.jboss.org/browse/ISPN-4549
Project: Infinispan
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Test Suite - Server
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Galder Zamarreño
Priority: Blocker
Labels: testsuite_stability
Fix For: 7.0.0.Beta1
The test checks that the rebalance is complete by waiting for the
{{CommittedViewAsString}} reported by the RpcManager MBean to be
{{"DefaultConsistentHash\{numSegments=60, numOwners=2, members=\[node0/" +
getCacheManagerName() + ", node1/" + getCacheManagerName() + "\]\}"}}
and the {{PendingViewAsString}} to be {{null}}.
But immediately after the 3rd server is stopped, the coordinator installs a topology with
exactly the same string representation. It only starts the rebalance after that.
So the test could start checking the number of entries before the rebalance actually
started.
Failure in CI:
http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDi...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)