cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Batey (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-12625) Distinguish between CAS prepare and propose failures
Date Sat, 10 Sep 2016 15:16:20 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christopher Batey updated CASSANDRA-12625:
------------------------------------------
    Labels: cas  (was: )

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

Mime
View raw message