[ 
https://issues.apache.org/jira/browse/CASSANDRA-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071873#comment-13071873
 ] 

David Phillips commented on CASSANDRA-2889:
-------------------------------------------

You can run this temporary fix before starting the server to bound the queue 
size:

{code}
private static void monkeyPatchCassandra()
{
    // hack to fix CASSANDRA-2889
    try {
        Field field = StageManager.class.getDeclaredField("stages");
        field.setAccessible(true);
        EnumMap<Stage, ThreadPoolExecutor> stages = (EnumMap<Stage, 
ThreadPoolExecutor>) field.get(StageManager.class);

        Stage stage = Stage.REPLICATE_ON_WRITE;
        stages.get(stage).shutdown();
        stages.put(stage, new JMXConfigurableThreadPoolExecutor(
                DatabaseDescriptor.getConcurrentReplicators(),
                StageManager.KEEPALIVE,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<Runnable>(100000),
                new NamedThreadFactory(stage.getJmxName()),
                stage.getJmxType()));
    }
    catch (Exception e) {
        throw new AssertionError(e);
    }
}
{code}

> 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

        

Reply via email to