cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-4723) Improve write timeout exceptions
Date Thu, 27 Sep 2012 14:24:09 GMT


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
# 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:
>             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:

View raw message