[
https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911203#comment-13911203
]
Michael Harris commented on CASSANDRA-6764:
-------------------------------------------
Carrino, does this change have the potential to cause any problems during
rolling upgrades? It looks like you're modifying an existing codepath to use a
new type that gets serialized to other nodes. That could be very...explosive.
Am I missing something? Rolling upgrades are pretty common for minor version
upgrades (correct me if I'm wrong Jonathan), so this is actually kind of scary.
> 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
> Fix For: 1.2.16
>
> Attachments: cassandra_6764_v2.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.1.5#6160)
