cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6125) Race condition in Gossip propagation
Date Thu, 18 Sep 2014 21:31:35 GMT


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

View raw message