cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4285) Atomic, eventually-consistent batches
Date Fri, 06 Jul 2012 16:15:34 GMT


Jonathan Ellis commented on CASSANDRA-4285:

bq. If you do RF=1, then each time a node dies (is upgraded or whatnot) you know that some
portion of batchlog writes on the cluster will suffer from timeouts (even if we retry on the
coordinator, the latency will still suffer). That's actually the main reason why I think RF=2
is a much much better default

Good point...  I tend to think in terms of optimizing for throughput, but I think you're right.

Our hands may be tied though, how do you default to RF=2 and not screw over single node clusters?
 I'd be okay with defaulting to RF=1 but logging a WARN on startup if it hasn't been changed.

bq. But whether we do coordinator-side retry is not directly related imho 

Agreed from a purely theoretical standpoint, but practically it's related in the sense that
clients see retries in general as painful.  So if we can get to a place where clients don't
need to retry except in obscure corner cases (obscure enough that imo ignoring them is reasonable)
then so much the better.

bq. a timeout when writting to the replicas means that the CL cannot be achieved at the current

Right, which is where the InProgressException comes in: your write is in progress, you won't
necessarily be able to read it yet, but you don't need to retry (unless you need to block
for readability).
> Atomic, eventually-consistent batches
> -------------------------------------
>                 Key: CASSANDRA-4285
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
> I discussed this in the context of triggers (CASSANDRA-1311) but it's useful as a standalone
feature as well.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message