[
https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951510#comment-13951510
]
Benedict commented on CASSANDRA-6764:
-------------------------------------
But reading it again it looks like you are right. I think both are sensible
tests, however, so I'll introduce a second test that checks the maximum size
also.
> Using Batch commitlog_sync is slow and doesn't actually batch writes
> --------------------------------------------------------------------
>
> Key: CASSANDRA-6764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6764
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: John Carrino
> Assignee: John Carrino
> Fix For: 2.1 beta2
>
> Attachments: 6764.fix.txt, cassandra_6764_v2.patch,
> cassandra_6764_v3.patch
>
>
> The assumption behind batch commit mode is that the client does it's own
> batching and wants to wait until the write is durable before returning. The
> problem is that the queue that cassandra uses under the covers only allows
> for a single ROW (RowMutation) per thread (concurrent_writes). This means
> that commitlog_sync_batch_window_in_ms should really be called sleep_between
> each_concurrent_writes_rows_in_ms.
> I assume the reason this slipped by for so long is that no one uses batch
> mode, probably because people say "it's slow". We need durability so this
> isn't an option.
> However it doesn't need to be this slow.
> Also, if you write a row that is larger than the commit log size it silently
> (warn) fails to put it in the commit log. This is not ideal for batch mode.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
