[
https://issues.apache.org/jira/browse/CASSANDRA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738683#action_12738683
]
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: https://issues.apache.org/jira/browse/CASSANDRA-195
> 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.
