[ 
https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026684#comment-13026684
 ] 

Gary Dusbabek commented on CASSANDRA-2536:
------------------------------------------

bq. Sometimes the v1 UUID generated by the second node has an earlier timestamp 
than the current schema UUID has.
Wouldn't that update be DOA then?  I thought we checked to make sure the new 
migration compared after the current migration (as well as making sure the new 
migration's previous version matches with the current version).

bq. A node shouldn't accept a schema change if the timestamp for the new schema 
would be earlier than its current schema.
If the clocks are *that* far off sync, I think the cluster has bigger problems 
(like writes not being applied). Plus, it would be easy for a node whose clock 
is way head to 'poison' schema updates from the rest of the cluster who are, in 
effect, behind the times.

bq. Schema modification calls should accept an optional client-side timestamp 
that will be used for the v1 UUID.
Seems like a better approach.



> Schema disagreements when using connections to multiple hosts
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-2536
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2536
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8 beta 1
>         Environment: Two node 0.8-beta1 cluster with one seed and JNA.
>            Reporter: Tyler Hobbs
>            Assignee: Tyler Hobbs
>         Attachments: schema_disagree.py
>
>
> If you have two thrift connections open to different nodes and you create a 
> KS using the first, then a CF in that KS using the second, you wind up with a 
> schema disagreement even if you wait/sleep after creating the KS.
> The attached script reproduces the issue using pycassa (1.0.6 should work 
> fine, although it has the 0.7 thrift-gen code).  It's also reproducible by 
> hand with two cassandra-cli sessions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to