You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2012/09/26 16:05:07 UTC
[jira] [Created] (CASSANDRA-4723) Improve write timeout exceptions
Sylvain Lebresne created CASSANDRA-4723:
-------------------------------------------
Summary: 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.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
[jira] [Updated] (CASSANDRA-4723) Improve write timeout exceptions
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4723:
----------------------------------------
Attachment: 4723.txt
Attaching patch that addresses both point above.
> 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.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
[jira] [Updated] (CASSANDRA-4723) Improve write timeout exceptions
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4723:
----------------------------------------
Attachment: 4723-alternative.txt
> 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
[jira] [Commented] (CASSANDRA-4723) Improve write timeout
exceptions
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464009#comment-13464009 ]
Sylvain Lebresne commented on CASSANDRA-4723:
---------------------------------------------
bq. shouldn't guaranteedAtomic be a constructor parameter
It can, though we have to do a bit of gymnastic to be able to pass the argument down there. Attaching an alternative patch that does that however. Not sure I have a preference between the two.
> 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
[jira] [Updated] (CASSANDRA-4723) Improve write timeout exceptions
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CASSANDRA-4723) Improve write timeout
exceptions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470688#comment-13470688 ]
Jonathan Ellis commented on CASSANDRA-4723:
-------------------------------------------
+1
> 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
[jira] [Commented] (CASSANDRA-4723) Improve write timeout
exceptions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463959#comment-13463959 ]
Jonathan Ellis commented on CASSANDRA-4723:
-------------------------------------------
shouldn't guaranteedAtomic be a constructor parameter, not get()?
> 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.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
[jira] [Commented] (CASSANDRA-4723) Improve write timeout
exceptions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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