[infinispan-issues] [JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer --------------------------------------------------------------------------------------- Key: ISPN-3918 URL: https://issues.jboss.org/browse/ISPN-3918 Project: Infinispan Issue Type: Bug Components: Core, State Transfer Affects Versions: 6.0.0.Final Reporter: Dan Berindei Priority: Major Labels: consistency Fix For: 10.0.1.Final Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls. Say \[B, A, C] are the owners of k (C just joined) 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B 2. B forwards the command to A and C 3. C writes {{k=v1}} 4. C becomes the primary owner of k (owners are now \[C, A]) 5. A/B see the new topology before committing and throw an outdatedTopologyException 6. A retries the command, sends it to C 7. C forwards the command to A, which writes {{k=v1}} 8. C doesn't have to update the entry, returns null If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.