Mailing-List: contact issues-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
Date: Mon, 17 Jul 2017 18:07:01 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: issues@geode.apache.org
Message-ID: <JIRA.13083550.1498760987000.265214.1500314821637@Atlassian.JIRA>
In-Reply-To: <JIRA.13083550.1498760987000@Atlassian.JIRA>
References: <JIRA.13083550.1498760987000@Atlassian.JIRA> <JIRA.13083550.1498760987889@jira-lw-us.apache.org>
Subject: [jira] [Commented] (GEODE-3153) Client receives duplicate events
 during rolling upgrade
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 17 Jul 2017 18:07:09 -0000


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

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

Commit 2974dab327c5d21e55a21c17fe657597a20c6612 in geode's branch refs/heads/master from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2974dab ]

GEODE-3153 applied spotless


> 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)