[jira] [Commented] (CASSANDRA-7822) Confusing timeout on CAS contention

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-7822:
---------------------------------------------

bq.  I think we might need to throw a separate exception for contention or may be add a flag in the timeout exception

We can easily do this in the next version of the native protocol, and we probably should, but not sure it's worth shoving in existing versions. That said, {{WriteType.CAS}} should pretty much means that there has been contention and user should probably not bother with the 'replica count' in that case. If it's just that the message in the client logs is confusing, maybe the client should write a message that is less confusing.

> Confusing timeout on CAS contention
> -----------------------------------
>
>                 Key: CASSANDRA-7822
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7822
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: sankalp kohli
>            Priority: Minor
>
> If we have contention in CAS and we hit the cas contention timeout, we throw an exception. In this timeout exception, we pass that 0 replicas responded. This is very confusing to someone looking at the client logs. I think we might need to throw a separate exception for contention or may be add a flag in the timeout exception. 
> We have seen many people confused by this so I think we should fix it. 
> This is how we throw it on contention. 
> throw new WriteTimeoutException(WriteType.CAS, consistencyForPaxos, 0, consistencyForPaxos.blockFor(Keyspace.open(keyspaceName)));



--
This message was sent by Atlassian JIRA
(v6.2#6252)