cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Herron (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5025) Schema push/pull race
Date Mon, 10 Dec 2012 00:49:21 GMT

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

Chris Herron updated CASSANDRA-5025:
------------------------------------

    Attachment: 5025-v5.txt

(Following up on IRC discussion)
* My patch 3 incorrectly hardcoded Schema.emptyVersion for the announcement in SS.joinTokenRing.
For actual bootstrap scenario, the schema version should be Schema.emptyVersion anyway. 
* Since Schema.updateVersion actually reads rows, I wondered if this will be equivalent to
   Schema.emptyVersion (perhaps Schema tables themselves are represented already by this point
in time?) Brandon said that he would check this.
* I had asked in a previous comment in this jira, and Brandon also noticed that SS.joinTokenRing
had been calling Schema.updateVersionAndAnnounce and Schema.passiveAnnounce in quick succession.
Brandon said that it should be removed.

I'm attaching patch 5 with these changes:
* Reverted my hardcoded Schema.emptyVersion in SS.joinTokenRing (back to original Schema.updateVersionAndAnnounce).
* Removed apparently redundant call to Schema.passiveAnnounce.

Brandon, could you please confirm whether it is safe to assume that Schema.updateVersionAndAnnounce
would emit Schema.emptyVersion in a bootstrap scenario?
 
                
> Schema push/pull race
> ---------------------
>
>                 Key: CASSANDRA-5025
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5025
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 1.1.8
>
>         Attachments: 5025.txt, 5025-v2.txt, 5025-v3.txt, 5025-v4.txt, 5025-v5.txt
>
>
> When a schema change is made, the coordinator pushes the delta to the other nodes in
the cluster.  This is more efficient than sending the entire schema.  But the coordinator
also announces the new schema version, so the other nodes' reception of the new version races
with processing the delta, and usually seeing the new schema wins.  So the other nodes also
issue a pull to the coordinator for the entire schema.
> Thus, schema changes tend to become O(n) in the number of KS and CF present.

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