You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Alex Petrov (Jira)" <ji...@apache.org> on 2020/01/31 18:08:00 UTC

[jira] [Commented] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.

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

Alex Petrov commented on CASSANDRA-15350:
-----------------------------------------

I've pushed a rebased branch with minor improvements [here|https://github.com/ifesdjeen/cassandra/tree/cas-exception-changes], tests running [here|https://circleci.com/gh/ifesdjeen/cassandra/tree/cas-exception-changes].

I'd propose to use fuzz tests instead of cascades of latches. If we could implement a simple test to reproduce (any) contention in this fashion, it'd be great. Could you implement it? 

Other than that, I'm +1 and ready to commit when contention fuzz test is added.

> Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-15350
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Feature/Lightweight Transactions
>            Reporter: Alex Petrov
>            Assignee: Yifan Cai
>            Priority: Normal
>              Labels: protocolv5, pull-request-available
>         Attachments: Utf8StringEncodeBench.java
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as WriteTimeout. One of this conditions it manifests is when there’s at least one acceptor that has accepted the value, which means that this value _may_ still get accepted during the later round, despite the proposer failure. Similar problem happens with CAS contention, which is also indistinguishable from the “regular” timeout, even though it is visible in metrics correctly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org