[
https://issues.apache.org/jira/browse/CASSANDRA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408116#comment-13408116
]
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 time
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: https://issues.apache.org/jira/browse/CASSANDRA-4285
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
