[jira] [Comment Edited] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures

["Christopher Batey (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15503208#comment-15503208 ] 

Christopher Batey edited comment on CASSANDRA-12625 at 9/19/16 12:01 PM:
-------------------------------------------------------------------------

{quote}
We can, though my preferred way of adding that information would probably be to add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if we can guarantee it won't be applied or not (could call it canSafelyReply for instance).
{quote}

Agreed. This can still be made applicable even if we entirely change our paxos algorithm e.g. epaxos

I'll put together a patch.


was (Author: chbatey):
??
We can, though my preferred way of adding that information would probably be to add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if we can guarantee it won't be applied or not (could call it canSafelyReply for instance). 
??

Agreed. This can still be made applicable even if we entirely change our paxos algorithm e.g. epaxos

I'll put together a patch.

> Distinguish between CAS prepare and propose failures
> ----------------------------------------------------
>
>                 Key: CASSANDRA-12625
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12625
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Christopher Batey
>            Assignee: Christopher Batey
>            Priority: Minor
>              Labels: cas
>             Fix For: 3.x
>
>
> I spoke to a lot of users at the summit and had the feedback that the hardest part of building applications using LWTs is dealing with WriteTimeouts of type CAS.
> Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I think we should add a separate WriteType for timing out during the prepare phase assuming we can advise users to retry the operation or be confident it has failed as it won't be completed by a later SERIAL read or LWT.
> We can't remove the ambiguity at the propose phase but this will remove one of the unknown cases.
> cc [~slebresne] [~bdeggleston] [~spodxx@gmail.com]
> Happy to do a patch for this but assuming it will need a native protocol change when can we do it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)