Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
Availability - Unavailable
-
Normal
-
Low Hanging Fruit
-
Adhoc Test
-
All
-
None
-
Description
This was discovered while testing upgrading an SSL enabled cluster from 3.0 to 4.0. The 3.0 cluster was configured to only listen on the ssl storage port. When the upgraded 4.0 node started it received a gossip messsage that triggered a shadow round before it had correctly set the messaging versions for the other endpoints.
Sending the message created the connection, but because the endpoint defaulted to VERSION_40 the initial connect attempt was to the regular storage_port. The 3.0 node was only listening on the ssl_storage_port, so the connection was refused and the OutboundConnection.onFailure handler was called. As the shadow
gossip round had queued up a message, the hasPending branch was followed and the connection was rescheduled, however the port is never recalculated as the original settings are used so it always fails.
Meanwhile, the node discovered information about peers through inbound connection and gossip updating the messaging version for the endpoint which could have been used to make a valid connection.
Attachments
Issue Links
- duplicates
-
CASSANDRA-14848 When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
- Resolved
- links to