[
https://issues.apache.org/jira/browse/CASSANDRA-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689422#comment-13689422
]
Jason Brown commented on CASSANDRA-5669:
----------------------------------------
Ahh, I see your point. Our upgrades are never that short, time-wise, when we
bounce a node for upgrade, A would usually mark B as dead and drop any messages.
Yes, I think your proposal will be fine, a little extra public traffic is
better than thrashing (all) connections. This will work now that we keep the
version with the OTC rather than in each individual message (as we did pre-1.2).
> ITC.close() resets peer msg version, causes connection thrashing in ec2
> during upgrade
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-5669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5669
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.5
> Reporter: Jason Brown
> Assignee: Jason Brown
> Priority: Minor
> Labels: gossip
> Fix For: 1.2.6, 2.0 beta 1
>
> Attachments: 5669-v1.diff
>
>
> While debugging the upgrading scenario described in CASSANDRA-5660, I
> discovered the ITC.close() will reset the message protocol version of a peer
> node that disconnects. CASSANDRA-5660 has a full description of the upgrade
> path, but basically the Ec2MultiRegionSnitch will close connections on the
> publicIP addr to reconnect on the privateIp, and this causes ITC to drop the
> message protocol version of previously known nodes. I think we want to hang
> onto that version so that when the newer node (re-)connects to the lower node
> version, it passes the correct protocol version rather than the current
> version (too high for the older node),the connection attempt getting dropped,
> and going through the dance again.
> To clarify, the 'thrashing' is at a rather low volume, from what I observed.
> Anecdotaly, perhaps one connection per second gets turned over.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
