[
https://issues.apache.org/jira/browse/CASSANDRA-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108321#comment-17108321
]
Aleksey Yeschenko edited comment on CASSANDRA-15727 at 5/15/20, 2:36 PM:
-------------------------------------------------------------------------
bq. Sorry that I'm late to this party, but might it be cleaner to move the
setting of messagingVersion into attempt since we already do it there, and
remove it from onCompletedHandshake/RETRY and the class constructor? This would
capture all possible reasons messagingVersion might have changed, and reduce
the verbosity of this particular point in the code, possibly keeping its intent
a bit clearer.
Good call. I'll ninja it, if nobody objects.
EDIT: may or may have not done it in 17caa288c311e0364f81f78a85831c36f0f4917e
was (Author: iamaleksey):
bq. Sorry that I'm late to this party, but might it be cleaner to move the
setting of messagingVersion into attempt since we already do it there, and
remove it from onCompletedHandshake/RETRY and the class constructor? This would
capture all possible reasons messagingVersion might have changed, and reduce
the verbosity of this particular point in the code, possibly keeping its intent
a bit clearer.
Good call. I'll ninja it, if nobody objects.
> Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if
> initial connection version incorrect
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15727
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
> Reporter: Jon Meredith
> Assignee: Jon Meredith
> Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]