Bruce Schuchardt created GEODE-5520:
---------------------------------------
Summary: 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
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)
