[jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072878#comment-16072878 ] 

ASF subversion and git services commented on GEODE-3153:
--------------------------------------------------------

Commit fb4e96bfbad9e66966fd13cd35499bc7f3a020e4 in geode's branch refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb4e96b ]

GEODE-3139 remove artifacts from classpath of backward-compatibility tests

reinstating this - passes precheckin

GEODE-3153 Client receives duplicate events during rolling upgrade

Another problem was found in backward-compatibility testing.  If a
1.0.0 client was receiving subscription events generated by a 1.0.0
peer "feeder" member and the events were routed through a 1.0.0 server
the client might see duplicate events when the server is stopped and
the client fails over to a 1.2.0 server holding its redundant
subscription queue.  This is especially possible if a large "ack"
period is established in the client.

The problem stems from the EventID deserialization/reserialization of
the memberID bytes when sending to a 1.0 client.  It was deserializing
using Version.CURRENT, which ignores the UUID bytes in the serialized ID.
Then it serialized the identifier using the client's version, which
includes the UUID bytes but which are zero due to the version used
in deserialization.


> Client receives duplicate events during rolling upgrade
> -------------------------------------------------------
>
>                 Key: GEODE-3153
>                 URL: https://issues.apache.org/jira/browse/GEODE-3153
>             Project: Geode
>          Issue Type: Bug
>          Components: client queues
>            Reporter: Dan Smith
>             Fix For: 1.2.0
>
>
> During a rolling upgrade from 1.1 to 1.2, we see 1.1 client receive duplicate events.
> This is the scenario
> 1) 1.1 peer is doing puts
> 2) 1.1 client has registered interest, and is connected to a 1.1 server
> 3) 1.1 server is upgraded to a 1.2 server
> 4) The client may receive some of the events that are being put twice.
> Looking further, it appears that when a put goes through a 1.1 server to a 1.1 client, the member id includes a 17 byte unique id as the last part of the serialized data. When the put goes through a 1.2 server, those 17 bytes become zeros.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)