[
https://issues.apache.org/jira/browse/CASSANDRA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-397.
--------------------------------------
Resolution: Won't Fix
Thinking about this further, I think the proposed solution (making bootstrap
sources responsible for forwarding writes to the targets during bootstrap) is
worse than the problem.
The reason is, we want to preserve ConsistencyLevel semantics during bootstrap,
and if a CL.quorum/all write is sent to a bootstrap target, it would have to
wait for the forwarded write to complete to report in turn that the write is
good.
Leaving write propagation to be done by the write originator means we don't
have this extra layer of latency.
I will create another ticket for making the write originator include bootstrap
targets in the consistency computation.
> bootstrap and ringcache
> -----------------------
>
> Key: CASSANDRA-397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-397
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Fix For: 0.5
>
>
> Bootstrap mode makes it easy to shoot yourself in the foot with RingCache
> (see CASSANDRA-197).
> One solution would be to have the node that is providing data to the new,
> bootstrapping node, echo writes to the new node. Currently, the coordinator
> node is in charge of including the new node as an "extra" replica, but if a
> fat client is using messagingservice directly with RingCache that doesn't
> work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
