[
https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4723:
----------------------------------------
Attachment: 4723-v2.txt
You are right, the guaranteedAtomicity boolean is not enough information.
Basically, I do want to distinguish between:
# I'm atomic and something has been written: that includes the case of logged
batches where the batch log has been successfully written, but also the single
inserts. In that case, your asked CL hasn't been achieve but there is almost
point in retrying (right away) given how writes work. You might want to log
that the CL hasn't been achieved or something but at least you're pretty sure
everything has been persisted and will be replicated eventually.
# I'm a logged batch but it's the log write that timeouted: in that case you
should always retry.
# I'm an unlogged batch: in that case, not cool. There is almost no point in
retrying right away with the same CL for the same reasons that in the first
case. However, contrarily to the first case, some part of the batch may have
not been persisted at all, so you might want to do something about that
(schedule retries for later, retry with a lower CL so that even if you can't
achieve the CL guaranteed required by your application, at least you know
everything is persisted, ...).
So anyway, I don't think we can do that with a single boolean, and beside there
is also the counter case so I'm attaching a (imho cleaner) v2 patch that use an
enum to tell exactly in which case we are (single mutation, unlogged batch,
logged batch but were the log write was successful, failure during the batch
log write, counter).
> Improve write timeout exceptions
> ---------------------------------
>
> Key: CASSANDRA-4723
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4723
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.2.0 beta 1
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0 beta 2
>
> Attachments: 4723-alternative.txt, 4723.txt, 4723-v2.txt
>
>
> Through the binary protocol (and to a lesser extend in thrift), we now expose
> more information with a timeout, so that clients can take the right decision
> as far as retrying the operation is concerned. Concerning write timeouts,
> there is two places where I think we should improve that a bit:
> * regarding batchlog writes: what clients are interested in is to know if the
> option was atomic basically. If it was, there is no good reason to retry the
> write, otherwise, you should (or at least you know there might be
> inconsistencies if you don't).
> * we should return a separate exception for counter writes as in that case no
> retry should ever be done.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
