[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-10-08 Thread Sam Tunnicliffe (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15193:

  Fix Version/s: (was: 3.11.x)
 (was: 3.0.x)
 4.0-alpha
 3.11.5
 3.0.19
  Since Version: 3.0.0
Source Control Link: 
https://github.com/apache/cassandra/commit/0388d89e29393d0b1f50baa24848bc8cb0a7c9a3
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Rebased and incorporated (most of) the review comments. There are no new test 
failures, so committed to 3.0 in {{0388d89e29393d0b1f50baa24848bc8cb0a7c9a3}} 
and merged to 3.11 and trunk. This isn't an issue in trunk so that only 
includes the new yaml setting, marked as deprecated and having no effect, to 
make upgrades from 2.1->3.x->4.0 less painful.
 
||branch||CI||
|[15193-3.0|https://github.com/beobal/cassandra/tree/15193-3.0]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15193-3.0]|
|[15193-3.11|https://github.com/beobal/cassandra/tree/15193-3.11]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15193-3.11]|
|[15193-trunk|https://github.com/beobal/cassandra/tree/15139-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/15139-trunk]|

dtests ran using the branch in this PR: 
https://github.com/apache/cassandra-dtest/pull/54


> 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
> Fix For: 3.0.19, 3.11.5, 4.0-alpha
>
>
> 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
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-10-07 Thread Aleksey Yeschenko (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-15193:
--
Status: Ready to Commit  (was: Review In Progress)

> 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
> Fix For: 3.0.x, 3.11.x
>
>
> 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
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-10-07 Thread Aleksey Yeschenko (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-15193:
--
Reviewers: Aleksey Yeschenko, Alex Petrov, Aleksey Yeschenko  (was: Aleksey 
Yeschenko, Alex Petrov)
   Aleksey Yeschenko, Alex Petrov, Aleksey Yeschenko  (was: Aleksey 
Yeschenko, Alex Petrov)
   Status: Review In Progress  (was: Patch Available)

> 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
> Fix For: 3.0.x, 3.11.x
>
>
> 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
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-07-09 Thread Sam Tunnicliffe (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15193:

Reviewers: Aleksey Yeschenko, Alex Petrov

> 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
> Fix For: 3.0.x, 3.11.x
>
>
> 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



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-07-09 Thread Sam Tunnicliffe (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15193:

Fix Version/s: 3.11.x
   3.0.x

> 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
> Fix For: 3.0.x, 3.11.x
>
>
> 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



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-07-09 Thread Sam Tunnicliffe (JIRA)


 [ 
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



[jira] [Updated] (CASSANDRA-15193) Add ability to cap max negotiable protocol version

2019-07-09 Thread Sam Tunnicliffe (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-15193:

 Severity: Normal
   Complexity: Normal
Discovered By: Unit Test
 Bug Category: Parent values: Availability(12983)Level 1 values: Response 
Crash(12991)
   Status: Open  (was: Triage Needed)

> 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