[
https://issues.apache.org/jira/browse/GEODE-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597522#comment-16597522
]
ASF subversion and git services commented on GEODE-5645:
--------------------------------------------------------
Commit ff56282cce85ca7802bf995ec3798c0c5916a140 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff56282 ]
GEODE-5645 Client cache misses invalidate
Notify clients/gateways on an invalidation that is overwriting an
existing invalidated entry. This allows them to update their version
information in case there is an operation that conflicts with this
invalidation and should be thrown away.
> Client cache misses invalidate
> ------------------------------
>
> Key: GEODE-5645
> URL: https://issues.apache.org/jira/browse/GEODE-5645
> Project: Geode
> Issue Type: Bug
> Components: client queues
> Reporter: Bruce Schuchardt
> Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a test with four clients and four servers with the clients performing
> concurrent operations on the same keys one of the clients missed an
> "invalidate" event and ended up being inconsistent.
> There was a cache entry in the servers sitting at version 2. Client4 is the
> cache that ends up being inconsistent by way of its subscription feed.
> client1 does v3 invalidate with server1
> client2 does v4 update with server2
> client3 does v5 invalidate with server3
> server4 receives v3 invalidate and informs clients
> client4 gets v3 invalidate through subscription
> server4 receives v5 invalidate and ignores it because its already invalidated
> server4 receives v4 update from server2
> server4 throws concurrency conflict exception for v4 update
> client4 gets v4 update (applied as a create) from server4 through subscription
> Clients with queues on other servers get the ops in order and end up with an
> invalidated entry.
> client4 does not get the final invalidate event and is inconsistent wrt other
> clients and the servers.
> With fine level logging the log statement that shows the problem happening is
> this:
> {noformat}
> mapInvalidate: Entry already invalid: 'Object_1683'
> {noformat}
> Where Object_1683 is the key for the entry we're dealing with.
> The code doing this is in AbstractRegionMap's invalidate() method:
> {code}
> if (oldRe.isInvalid()) {
> // was already invalid, do not invoke listeners or
> increment stat
> if (isDebugEnabled) {
> logger.debug("mapInvalidate: Entry already invalid:
> '{}'",
> event.getKey());
> }
> processVersionTag(oldRe, event);
> try {
> oldRe.setValue(owner, oldRe.getValueInVM(owner));
> // OFFHEAP noop setting
>
> // an already invalid to
>
> // invalid; No need to
>
> // call
>
> // prepareValueForCache
>
> // since it is an
>
> // invalid token.
> } catch (RegionClearedException e) {
> // that's okay - when writing an invalid into a
> disk, the
> // region has been cleared (including this token)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
