[
https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464047#comment-13464047
]
Jonathan Ellis commented on CASSANDRA-4723:
-------------------------------------------
I do like this better.
Not sure if this does what we want though. Basically: we should retry unless
mutateAtomically succeeded w/ the batchlog write. But performWrite is not
called from mutateAtomically but it can still pass atomic=true.
"atomicness" is probably not the right information to return, since a
single-key write is atomic but still needs retry if it is not part of
mutateAtomically.
> 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
>
>
> 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
