[
https://issues.apache.org/jira/browse/CASSANDRA-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2889:
----------------------------------------
Attachment: 2889.txt
Forgot a bit about this issue. Attaching a simple patch to simply limit the
queue size for the replicate_on_write stage. My intuition is that this is
probably "good enough" so not sure if it's worth getting much more fancy.
> 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
> Fix For: 1.1.1
>
> Attachments: 2889.txt
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
