Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 18 Sep 2014 21:31:35 +0000 (UTC)
From: "Jason Brown (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12671644.1380654072000.69889.1411075895184@Atlassian.JIRA>
In-Reply-To: <JIRA.12671644.1380654072000@Atlassian.JIRA>
References: <JIRA.12671644.1380654072000@Atlassian.JIRA>
 <JIRA.12671644.1380654072856@arcas>
Subject: [jira] [Commented] (CASSANDRA-6125) Race condition in Gossip
 propagation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jason Brown commented on CASSANDRA-6125:
----------------------------------------

+1 on the patch, and I agree with [~brandon.williams]'s thoughts on keeping the protocol simple. As long as versioned values are added to the endpointState in the order in which you assign versions (which this patch provides), there should be no problem. This should be a low bar to clear for anyone who really wants to muck around in gossip-land :).


> Race condition in Gossip propagation
> ------------------------------------
>
>                 Key: CASSANDRA-6125
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6125
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sergio Bossa
>            Assignee: Brandon Williams
>             Fix For: 2.0.11
>
>         Attachments: 6125.txt
>
>
> Gossip propagation has a race when concurrent VersionedValues are created and submitted/propagated, causing some updates to be lost, even if happening on different ApplicationStatuses.
> That's what happens basically:
> 1) A new VersionedValue V1 is created with version X.
> 2) A new VersionedValue V2 is created with version Y = X + 1.
> 3) V2 is added to the endpoint state map and propagated.
> 4) Nodes register Y as max version seen.
> 5) At this point, V1 is added to the endpoint state map and propagated too.
> 6) V1 version is X < Y, so nodes do not ask for his value after digests.
> A possible solution would be to propagate/track per-ApplicationStatus versions, possibly encoding them to avoid network overhead.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)