geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-5520) Inconsistency created by delta-propagation interaction with concurrency control
Date Thu, 02 Aug 2018 23:21:00 GMT

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

ASF GitHub Bot updated GEODE-5520:
----------------------------------
    Labels: pull-request-available  (was: )

> 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
>
> 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)

Mime
View raw message