Re: drop/recreate column family race condition
truncate doesn't change schema, it just drops the data associated with it. so it's a different beast from either normal writes or schema change. truncate will wait for each node to response, and send a TimedOutException if any do not. On Tue, Sep 7, 2010 at 5:42 PM, B. Todd Burruss wrote: > interesting is that "truncate" API doesn't return a schema version nor take > a consistency level. does this mean that when it returns the cluster is > always consistent? > > On 09/07/2010 02:50 PM, Jonathan Ellis wrote: >> >> On Tue, Sep 7, 2010 at 4:29 PM, B. Todd Burruss wrote: >> >>> >>> if you are referring to R, W, N - i am aware, but i have a one node >>> cluster, >>> with R=W=N = 1. single threaded test app. any column manipulations >>> would >>> be immediate because R+W>N, so i assume the same for column family >>> manipulations. is this an invalid assumption? >>> >> >> Gary can correct me if I'm wrong, but schema change is always >> asynchronous as you can tell by having no ConsistencyLevel associated >> with the calls. You need to call check_schema_agreement to make sure >> that the nodes are on the version returned by the migration call. >> >> > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: drop/recreate column family race condition
interesting is that "truncate" API doesn't return a schema version nor take a consistency level. does this mean that when it returns the cluster is always consistent? On 09/07/2010 02:50 PM, Jonathan Ellis wrote: On Tue, Sep 7, 2010 at 4:29 PM, B. Todd Burruss wrote: if you are referring to R, W, N - i am aware, but i have a one node cluster, with R=W=N = 1. single threaded test app. any column manipulations would be immediate because R+W>N, so i assume the same for column family manipulations. is this an invalid assumption? Gary can correct me if I'm wrong, but schema change is always asynchronous as you can tell by having no ConsistencyLevel associated with the calls. You need to call check_schema_agreement to make sure that the nodes are on the version returned by the migration call.
Re: drop/recreate column family race condition
On Tue, Sep 7, 2010 at 4:29 PM, B. Todd Burruss wrote: > if you are referring to R, W, N - i am aware, but i have a one node cluster, > with R=W=N = 1. single threaded test app. any column manipulations would > be immediate because R+W>N, so i assume the same for column family > manipulations. is this an invalid assumption? Gary can correct me if I'm wrong, but schema change is always asynchronous as you can tell by having no ConsistencyLevel associated with the calls. You need to call check_schema_agreement to make sure that the nodes are on the version returned by the migration call. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: drop/recreate column family race condition
5 secs isn't enough for me, 10 is good. i haven't tried any other values as i can get around this through another manner. On 09/07/2010 02:24 PM, Edward Capriolo wrote: On Tue, Sep 7, 2010 at 5:10 PM, Jonathan Ellis wrote: On Tue, Sep 7, 2010 at 3:55 PM, B. Todd Burruss wrote: using 0.7 latest from trunk as of few minutes ago. 1 client, 1 node i have the scenario where i want to drop a column family and recreate it - unit testing for instance, is a good reason you may want to do this (always start fresh). the problem i observe is that if i do the following: 1 - drop the column family 2 - recreate it 3 - read data from a key that existed before dropping, but doesn't exist now if those steps happen fast enough, i will get the old row - definitely no good. old rows can appear until the drop is complete. as you're aware, this is part of the design. if they happen slow enough, get_slice throws: this is definitely a bug. Can you open a ticket? BTW, is there a reason you're not using truncate instead of drop/recreate? It's lighter-weight since it doesn't have to do a schema migration. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com I am using truncate in one of my unit test. I added in a 1 second sleep after calling it. Does that seem reasonable?
Re: drop/recreate column family race condition
https://issues.apache.org/jira/browse/CASSANDRA-1477 comments below On 09/07/2010 02:10 PM, Jonathan Ellis wrote: On Tue, Sep 7, 2010 at 3:55 PM, B. Todd Burruss wrote: using 0.7 latest from trunk as of few minutes ago. 1 client, 1 node i have the scenario where i want to drop a column family and recreate it - unit testing for instance, is a good reason you may want to do this (always start fresh). the problem i observe is that if i do the following: 1 - drop the column family 2 - recreate it 3 - read data from a key that existed before dropping, but doesn't exist now if those steps happen fast enough, i will get the old row - definitely no good. old rows can appear until the drop is complete. as you're aware, this is part of the design. if you are referring to R, W, N - i am aware, but i have a one node cluster, with R=W=N = 1. single threaded test app. any column manipulations would be immediate because R+W>N, so i assume the same for column family manipulations. is this an invalid assumption? if they happen slow enough, get_slice throws: this is definitely a bug. Can you open a ticket? BTW, is there a reason you're not using truncate instead of drop/recreate? It's lighter-weight since it doesn't have to do a schema migration. no reason, i can switch
Re: drop/recreate column family race condition
On Tue, Sep 7, 2010 at 5:10 PM, Jonathan Ellis wrote: > On Tue, Sep 7, 2010 at 3:55 PM, B. Todd Burruss wrote: >> using 0.7 latest from trunk as of few minutes ago. 1 client, 1 node >> >> i have the scenario where i want to drop a column family and recreate it - >> unit testing for instance, is a good reason you may want to do this (always >> start fresh). >> >> the problem i observe is that if i do the following: >> >> 1 - drop the column family >> 2 - recreate it >> 3 - read data from a key that existed before dropping, but doesn't exist now >> >> if those steps happen fast enough, i will get the old row - definitely no >> good. > > old rows can appear until the drop is complete. as you're aware, this > is part of the design. > >> if they happen slow enough, get_slice throws: > > this is definitely a bug. Can you open a ticket? > > BTW, is there a reason you're not using truncate instead of > drop/recreate? It's lighter-weight since it doesn't have to do a > schema migration. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com > I am using truncate in one of my unit test. I added in a 1 second sleep after calling it. Does that seem reasonable?
Re: drop/recreate column family race condition
On Tue, Sep 7, 2010 at 3:55 PM, B. Todd Burruss wrote: > using 0.7 latest from trunk as of few minutes ago. 1 client, 1 node > > i have the scenario where i want to drop a column family and recreate it - > unit testing for instance, is a good reason you may want to do this (always > start fresh). > > the problem i observe is that if i do the following: > > 1 - drop the column family > 2 - recreate it > 3 - read data from a key that existed before dropping, but doesn't exist now > > if those steps happen fast enough, i will get the old row - definitely no > good. old rows can appear until the drop is complete. as you're aware, this is part of the design. > if they happen slow enough, get_slice throws: this is definitely a bug. Can you open a ticket? BTW, is there a reason you're not using truncate instead of drop/recreate? It's lighter-weight since it doesn't have to do a schema migration. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
