[infinispan-issues] [JBoss JIRA] (ISPN-3197) Message ordering of Get and Invalidation can cause L1 to be inconsistent

[William Burns (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Burns updated ISPN-3197:
--------------------------------

              Status: Pull Request Sent  (was: Coding In Progress)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/1922

    
> 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&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12779491
> 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: http://www.atlassian.com/software/jira