[ https://issues.apache.org/jira/browse/GEODE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090194#comment-16090194 ]
ASF subversion and git services commented on GEODE-3153: -------------------------------------------------------- Commit 30e2eb2080afff3af2f5226a412259c3a5302f63 in geode's branch refs/heads/master from [~bschuchardt] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=30e2eb2 ] 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)