[
https://issues.apache.org/jira/browse/CASSANDRA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep Tata updated CASSANDRA-195:
-----------------------------------
Attachment: 195-v4-delta1.patch
>>okay, so this should really be a flag, instead of a boolean.
We can do this either way. Moving to a check like:
boolean bootstrapState =
epState.getApplicationState(StorageService.BOOTSTRAP_MODE) != null;
will need the compensating action in removeBootstrapSource() to delete
application state.
This has the advantage of slightly reducing the size of gossip messages when
bootstrap is complete/absent.
v4-delta1 does this.
> 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-delta1.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.
