cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5669) ITC.close() resets peer msg version, causes connection thrashing in ec2 during upgrade
Date Wed, 19 Jun 2013 22:54:20 GMT

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

Jason Brown updated CASSANDRA-5669:
-----------------------------------

    Attachment: 5669-v1.diff

Attached patch simply deletes the call to Gossiper.resetVersion() from ITC.close().
                
> 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.

--
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

Mime
View raw message