Dan Berindei created ISPN-9109: ---------------------------------- Summary: Commands may be executed in the wrong order after a merge Key: ISPN-9109 URL: https://issues.jboss.org/browse/ISPN-9109 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.3.0.Alpha1, 9.2.1.Final Reporter: Dan Berindei This is related to ISPN-9104, but it applies to any commands in a REPL_SYNC cache. We have a topology id check to avoid running commands from an older topology, but if the cluster splits cleanly in 2, then both partitions rebalance and install a topology with the same id. After the partitions merge, commands that were broadcast in one partition are retransmitted by NAKACK2 to the nodes in the other partition, and they will have the right topology id (until the post-merge cache topology update is received) so they will be executed. The worst scenario is in a transactional cache, where you could have node A in partition \[AB\] broadcast a lock acquisition command ({{LockControlCommand}} in a pessimistic cache, or {{PrepareCommand}} in an optimistic cache), wait for the responses, and then broadcast a lock release command (1-phase {{PrepareCommand}}, {{CommitCommand}}, or {{TxCompletionNotificationCommand}}). In partition \[AB\], the {{TxCompletionNotificationCommand}} is only sent after all the nodes confirmed that they acquired the lock. When partitions \[AB\] and \[CD\] merge, C and D receive both commands, but there's no guarantee that they will be processed in the right order. If the lock release command runs first, it won't do anything, then the lock acquisition command will acquire the lock, and no other command is going to release it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)