Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 19 Sep 2016 10:39:20 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13004079.1473520514000.604313.1474281560656@Atlassian.JIRA>
In-Reply-To: <JIRA.13004079.1473520514000@Atlassian.JIRA>
References: <JIRA.13004079.1473520514000@Atlassian.JIRA> <JIRA.13004079.1473520514229@arcas>
Subject: [jira] [Commented] (CASSANDRA-12625) Distinguish between CAS
 prepare and propose failures
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 19 Sep 2016 10:39:22 -0000


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

Sylvain Lebresne commented on CASSANDRA-12625:
----------------------------------------------

bq. the feedback that the hardest part of building applications using LWTs is dealing with WriteTimeouts of type CAS

I have no problem believing that, this would have been my pick too if I had been asked.

bq.  think we should add a separate WriteType for timing out during the prepare phase

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). This feels cleaner to me.

With that said, as said in CASSANDRA-8672, I don't think this will simplify application building. The nasty part of dealing with write timeouts on CAS is when you don't know if the write has/may be applied or not and you will still have to deal with that. Having the distinction of the ticket is more an optimization that allow a faster strategy (just retry) when you timeout during prepare, but you'll still need the more complex code for the other cases. Doesn't mean we can't optimize of course.

bq. assuming it will need a native protocol change when can we do it?

It will indeed require a protocol change and since CASSANDRA-12142 we can _commit_ changes for v5. But v5 will probably only be finalized for Cassandra 4.0.

> 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)