geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-3153) Client receives duplicate events during rolling upgrade
Date Mon, 03 Jul 2017 20:12:00 GMT


ASF subversion and git services commented on GEODE-3153:

Commit 30e2eb2080afff3af2f5226a412259c3a5302f63 in geode's branch refs/heads/release/1.2.0
from [~bschuchardt]
[;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:
>             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

View raw message