Arvind Kandpal created CASSANDRA-21838:
------------------------------------------
Summary: 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
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]
