]
Mircea Markus updated ISPN-3197:
--------------------------------
Affects Version/s: 5.2.6.Final
Message ordering of Get and Invalidation can cause L1 to be
inconsistent
------------------------------------------------------------------------
Key: ISPN-3197
URL:
https://issues.jboss.org/browse/ISPN-3197
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.2.6.Final
Reporter: William Burns
Assignee: William Burns
This is based off of discussion here:
https://issues.jboss.org/browse/ISPN-2990?focusedCommentId=12779491&p...
This can occur with a synchronous cache.
1. A reads k1. This is an OOB call.
2. B processes the read message and sends back the response
3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
4. A processes(ignores) the invalidation message
5. A puts the stale value sent at 2 in L1
The OOB portions don't actually matter that they are OOB as even if B's messages
were ordered it sill could process the get and update in a different order since they
originate from different nodes.
The initial thought is to solve this with some type of tombstone to sygnal the removal of
the L1 cache, but this also still doesn't catch the problem if A did not have key k1
in it's L1 cache to receive an invalidation message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: