cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-14802) calculatePendingRanges assigns more pending ranges than necessary
Date Tue, 05 Mar 2019 15:25:00 GMT


Sam Tunnicliffe updated CASSANDRA-14802:
    Status: Patch Available  (was: Open)

The {{BOOTSTRAP_REPLACE}} case is, I think, relatively straightforward to fix. As this is
fairly simple to reason about/implement/test, IMO we could consider it for 4.0 and defer the
more complex general case for now. This isn't a new regression and getting it right (&
validating it) is going to be quite involved, so it feels a bit of a risk for the 4.0 timeframe.


> calculatePendingRanges assigns more pending ranges than necessary 
> ------------------------------------------------------------------
>                 Key: CASSANDRA-14802
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Coordination, Legacy/Distributed Metadata
>            Reporter: Benedict
>            Priority: Major
>             Fix For: 4.x
> This might be a good thing, but should probably be configurable, and made consistent.
 Presently, in a number of circumstances where there are multiple range movements, {{calculatePendingRanges}}
will assign a pending range to a node that will not ultimately own it.  If done consistently,
this might make range movements resilient to node failures / aborted range movements, since
all nodes will be receiving all ranges they might own under any incomplete range ownership
movements.  But done inconsistently it seems only to reduce availability in the cluster, by
potentially increasing the number of pending nodes unnecessarily.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message