cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tata (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-195) Improve bootstrap algorithm
Date Mon, 03 Aug 2009 23:39:17 GMT


Sandeep Tata commented on CASSANDRA-195:

What if a client ends up submitting a write/read to a node in "bootstrap mode" ? (Could happen
in a few scenarios)

We have three options:
1. Throw an UnavailableException (easy :) )
2. Forward the request to one of the older nodes that has the data
3. Prevent such a scenario in the first place by not gossiping the token of the new node until
it is out of the bootstrap mode (complicated, probably unnecessary)

I'm leaning towards Option #2 being the best compromise: R/W still available, but at an extra
hop until bootstrap completes.

> Improve bootstrap algorithm
> ---------------------------
>                 Key: CASSANDRA-195
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: all
>            Reporter: Sandeep Tata
>             Fix For: 0.5
> When you add a node to an existing cluster and the map gets updated, the new node may
respond to read requests by saying it doesn't have any of the data until it gets the data
from the node(s) the previously owned this range (the load-balancing code, when working properly
can take care of this). While this behaviour is compatible with eventual consistency, it would
be much friendlier for the new node not to "surface" in the EndPoint maps for reads until
it has transferred the data over from the old nodes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message