[jira] [Resolved] (GEODE-5520) Inconsistency created by delta-propagation interaction with concurrency control

["Bruce Schuchardt (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Schuchardt resolved GEODE-5520.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.8.0

> Inconsistency created by delta-propagation interaction with concurrency control
> -------------------------------------------------------------------------------
>
>                 Key: GEODE-5520
>                 URL: https://issues.apache.org/jira/browse/GEODE-5520
>             Project: Geode
>          Issue Type: Bug
>          Components: client/server, messaging, regions, serialization
>            Reporter: Bruce Schuchardt
>            Assignee: Bruce Schuchardt
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.8.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> I tracked a cache inconsistency down to a delta propagation operation that failed over from one server to another and then failed to apply the delta on the new server.
> When the full value is sent from the client the message is not marked as a possible-duplicate.  Because it was missing this flag the server did not try to recover a concurrency version tag for the operation but instead generated a new version.
> When this server propagated the operation to another server it was rejected by that server because it had already processed the operation from the client's original attempt.  It recognized this by way of the operation's EventID being recorded in its EventTracker.
> This resulted in one server having version X and the other having version X+1 for the entry.
> The client then destroyed the same entry with the same server, generating version X+1 in that server.  When the server propagated the operation the other server already had X+1 and threw a ConcurrentCacheModificationException.  The result was one server having a tombstone for the entry and the other having the value from the delta-propagation operation.
> This can be fixed by setting the possible-duplicate flag on the message from the client that contains the full value.  The server will then search for a concurrency version tag and use it instead of generating a new one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)