[
https://issues.apache.org/jira/browse/CASSANDRA-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083261#comment-13083261
]
Sylvain Lebresne commented on CASSANDRA-2889:
---------------------------------------------
bq. Is this the same as CASSANDRA-2892?
No, CASSANDRA-2892 was really just saying "if we have nothing to replicate to,
let's not push a replication task that will do nothing anyway". It was really
just a super easy optimization for the RF=1 case.
This one is because at CL.ONE, we ack the client as soon as we have written the
local mutation. But the replication involves a read. So if you write very
quickly at CL.ONE, you're "read to replicate" task may stack up because you're
not able to do them fast enough. But maybe the best solution here would be to
make CL.ONE wait for the read to have happened to ack the client. The current
make for a better latency at CL.ONE, but this is kind of a lie, because the
hardest part of the work (the read) till happens in the background, and it is
thus easy to flood the node.
> Avoids having replicate on write tasks stacking up at CL.ONE
> ------------------------------------------------------------
>
> Key: CASSANDRA-2889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2889
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.8.0
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Labels: counters
>
> The counter design involves a read on the first replica during a write. At
> CL.ONE, this read is not involved in the latency of the operation (the write
> is acknowledged before). This means it is fairly easy to insert too quickly
> at CL.ONE and have the replicate on write tasks falling behind. The goal of
> this ticket is to protect against that.
> An option could be to bound the replicate on write task queue so that write
> start to block once we have too much of those in the queue. Another option
> could be to drop the oldest tasks when they are too old, but it's probably a
> more unsafe option.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
