[jira] [Commented] (CASSANDRA-2889) Avoids having replicate on write tasks stacking up at CL.ONE

["David Phillips (JIRA)" <ji...@apache.org>]

    [ 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