[
https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913545#comment-13913545
]
Benedict commented on CASSANDRA-6764:
-------------------------------------
I think there's something to be said for refusing a mutation that couldn't be
guaranteed to be durable. People running batch CL are obviously more paranoid
about that already, and a warning is a bit late to fix it, especially if it's
on the server logs (which we know all good boys and girls read, but not
everyone is a good boy or girl.
I wouldn't want to break people who are using the old behaviour, but I'm also
ambivalent about more config parameters. I'd say if we had to choose, I'd lean
in favour of durability, since this is our durability mode. People who aren't
losing sleep over this are running periodic already. If we can find an
unobtrusive/uncluttered way to make it optional, let's do that, but otherwise
I'd make the switch with a major release when people are expected to be doing
some degree of due diligence.
There is one other possibility: we could create a whole CLS (of sufficient
size) for the monster mutation, and guarantee never to drop any from CL. This
would probably want to be configurable anyway, though, as could be a large
penalty for such huge durable writes.
> 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, 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.1.5#6160)
