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

Arvind Kandpal commented on CASSANDRA-21838:
--------------------------------------------

Hi [~stefan.miklosovic] , Please review it whenever get chance.

> Write_timeout with writeType CAS is sent without <contentions> on protocol v5 
> for Accord and Paxos v2 lock timeouts
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-21838
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21838
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Accord, Messaging/Client
>            Reporter: Arvind Kandpal
>            Assignee: Arvind Kandpal
>            Priority: Normal
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> On protocol v5, a Write_timeout error with writeType "CAS" carries a 
> <contentions> [short] (native_protocol_v5.spec, Section 8). Cassandra's own 
> decoder reads this short whenever writeType is CAS, but the encoder only 
> writes it when the exception is a CasWriteTimeoutException.
> Accord write timeouts (RequestBookkeeping.newTimeout, 
> AccordWritePreemptedException, AccordWriteExhaustedException) and the Paxos 
> v2 coordinator lock timeout (PaxosState.throwTimeout) throw a plain 
> WriteTimeoutException with writeType CAS. So on v5 they are sent without the 
> short. A client that follows the spec reads 2 bytes too many and either fails 
> or reads into the next envelope.
> Legacy Paxos has the opposite problem: it wraps a commit timeout (writeType 
> SIMPLE) in a CasWriteTimeoutException, so 2 extra bytes are sent that no 
> decoder reads.
> How to reproduce: on a 2-node cluster with a table using 
> transactional_mode='full', drop ACCORD_PRE_ACCEPT_REQ from node1 to node2 and 
> run INSERT ... IF NOT EXISTS with SimpleClient on protocol v5. The server 
> returns a write timeout, but the client fails to decode it 
> (IndexOutOfBoundsException in ErrorMessage decode) and only sees its own 
> timeout.
> Expected: the client decodes a CAS write timeout cleanly.
> Actual: the client fails to decode the error.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to