[ https://issues.jboss.org/browse/ISPN-8993?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8993: ------------------------------- Description: When the coordinator changes, either because the old one left or because there was a merge, the new coordinator first resets any ongoing rebalance, and then starts a rebalance with the new members. But some nodes could see the post-merge rebalance before the post-merge reset, and they need to reset any old data or inbound transfers first. [LocalTopologyManagerImpl|https://github.com/infinispan/infinispan/blob/22...] is responsible for faking that reset topology update, in order to keep StateConsumerImpl simpler. The problem is that LocalTopologyManagerImpl also creates a reset topology update if the new coordinator started conflict resolution, and that topology update clears all the segments not owned by the local node in the preferred topology. was: When the coordinator changes, either because the old one left or because there was a merge, the new coordinator first resets any ongoing rebalance, and then starts a rebalance with the new members. But some nodes could see the post-merge rebalance before the post-merge reset, and they need to reset any old data or inbound transfers first. [LocalTopologyManagerImpl|https://github.com/infinispan/infinispan/blob/22...] is responsible for faking that reset topology update, in order to keep StateConsumerImpl simpler. The problem is that LocalTopologyManagerImpl also creates a reset topology update if the new coordinator started conflict resolution. -- This message was sent by Atlassian JIRA (v7.5.0#75005)