[
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15193:
----------------------------------------
Test and Documentation Plan: Expanded unit test coverage
Status: Patch Available (was: Open)
Added a yaml setting to force the max negotiable protocol version to a specific
value. If this setting isn't used, then the maximum version will be determined
based on the C* version of the peers in the {{system.peers}} table. At startup,
if any peer is believed to be running a version lower than {{3.0.0}} ({{2.2}}
suffers the same problems as {{2.1}}), then the maximum protocol version that
may be negotiated will be capped at {{V3}}. As updated peer info is received
via gossip, the conditions are reevaluated and ultimately the cap will be
removed when all known peers are reporting version {{3.0.0}} or above. It isn't
safe to allow the cap to move in the other direction (i.e. to lower the max
negotiable version) while there may be clients already connected, so this is
essentially a one-way valve. There's also a system property that can be used to
disable this automatic limiting:
{{cassandra.disable_max_protocol_auto_override}}
||branch||CI||
|[15193-3.0|https://github.com/beobal/cassandra/tree/15193-3.0]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F15193-3.0]|
|[15193-3.11|https://github.com/beobal/cassandra/tree/15193-3.11]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F15193-3.11]|
This required a small tweak to one dtest (the circle workflows are using this
branch), see
[here|https://github.com/apache/cassandra-dtest/compare/master...beobal:15193]
> Add ability to cap max negotiable protocol version
> --------------------------------------------------
>
> Key: CASSANDRA-15193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15193
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
>
> 3.0 and native protocol V4 introduced a change to how PagingState is
> serialized. Unfortunately that can break requests during upgrades: since
> paging states are opaque, it's possible for a client to receive a paging
> state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4
> session. The version of the current session will be used to deserialize the
> paging state, instead of the actual version used to serialize it, and the
> request will fail.
> CASSANDRA-15176 solves half of this problem by enabling 3.0 nodes to
> serialize mis-versioned PagingStates. To address the other side of the issue,
> 2.1 nodes receiving V4 PagingStates, we can introduce a property to cap the
> max native protocol version that the 3.0 nodes will negotiate with clients.
> If we cap this to V3 during upgrades, no V4 connections will be established
> and so no incompatible PagingStates will be sent to clients.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
