cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Whiteside (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms
Date Fri, 08 May 2015 20:12:01 GMT

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

Aaron Whiteside edited comment on CASSANDRA-9328 at 5/8/15 8:11 PM:
--------------------------------------------------------------------

{quote}
 And since a WriteTimeoutException already means "I don't know", we throw it in that case
too, even though it's not a proper timeout per-se. The point being, you should handle it as
if it was a timeout.
{quote}
Is at odds with..
{quote}
A WTE means that update may or may not be applied, so yes, the update may have succeeded if
you get a WTE.
{quote}

If CAS is not atomic, and you shouldn't retry WTEs because it may cause inconsistent data..
The application cannot go back and read a record after a WTE because someone else might have
updated the value (race) and it might not be possible for the application to tell if it should
retry or not (based on the value).

For CAS in cassandra to work correctly (At the moment) you must ensure the data you update
is idempotent and if that is the case you probably wouldn't be using CAS in the first place..



was (Author: aaronjwhiteside):
{quote}
 And since a WriteTimeoutException already means "I don't know", we throw it in that case
too, even though it's not a proper timeout per-se. The point being, you should handle it as
if it was a timeout.
{quote}
Is at odds with..
{quote}
A WTE means that update may or may not be applied, so yes, the update may have succeeded if
you get a WTE.
{quote}

CAS is not atomic, and you shouldn't retry WTEs because it may cause inconsistent data.. The
application cannot go back and read a record after a WTE because someone else might have updated
the value (race) and it might not be possible for the application to tell if it should retry
or not (based on the value).

For CAS in cassandra to work correctly (At the moment) you must ensure the data you update
is idempotent and if that is the case you probably wouldn't be using CAS in the first place..


> WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration
taking MUCH less than cas_contention_timeout_in_ms
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9328
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Aaron Whiteside
>            Assignee: Benjamin Lerer
>            Priority: Critical
>             Fix For: 2.1.x
>
>         Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration
taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If the WTE
is due to not being able to communicate with other nodes, why does the concurrency >1 cause
inter-node communication to fail?



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

Mime
View raw message