[
https://issues.apache.org/jira/browse/CASSANDRA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744646#action_12744646
]
Sandeep Tata commented on CASSANDRA-195:
----------------------------------------
>> I don't see any actual uses of bootstrapNodes, though -- did you have
>> something in mind?
Yes. To do the forwarding of the writes.
The writes don't need to physically see a different ring, just that the
bootstrap node be included in the list of nodes an endpoint needs to write to.
>> ApplicationState bState =
>> epState.getApplicationState(StorageService.BOOTSTRAP_MODE);
>> assert bState != null;
That wouldn't work for the case when the cluster was started with no
bootstrapping nodes.
The gossiper always sends the full endpoint state, but the state may not
contain an entry for BOOTSTRAP_MODE which should be interpreted as normal mode.
> 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
> Assignee: Sandeep Tata
> Fix For: 0.5
>
> Attachments: 195-v1.patch, 195-v2.patch, 195-v3-delta1.patch,
> 195-v3.patch, 195-v4.patch
>
>
> 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.
