[
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
