[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org