You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Jeffrey Wang <jw...@palantir.com> on 2011/04/16 01:04:40 UTC
DatabaseDescriptor.defsVersion
Hey all,
I've been seeing a very rare issue with schema change conflicts on 0.7.3 (I am serializing all schema changes to a single Cassandra node and waiting for them to finish before continuing). Occasionally a node in the cluster will never report the correct schema, and I think it may have to do with synchronization on DatabaseDescriptor.defsVersion.
As far as I can tell, it is a static variable accessed by multiple threads but is not protected by synchronized/volatile. I was able to write a test in which one thread never reads the modification done by another thread (as is expected by an unsynchronized variable). Should this be fixed or is there a higher level reason this does not need to be synchronized (in which case I should continue looking for the reason why my schemas don't agree)? Thanks.
-Jeffrey
RE: DatabaseDescriptor.defsVersion
Posted by Jeffrey Wang <jw...@palantir.com>.
Done: https://issues.apache.org/jira/browse/CASSANDRA-2490
-Jeffrey
-----Original Message-----
From: Jonathan Ellis [mailto:jbellis@gmail.com]
Sent: Friday, April 15, 2011 7:39 PM
To: user@cassandra.apache.org
Cc: Jeffrey Wang
Subject: Re: DatabaseDescriptor.defsVersion
I think you found a bug; it should be volatile. (Cassandra does
already make sure that only one change runs internally at a time.)
Can you create a ticket?
On Fri, Apr 15, 2011 at 6:04 PM, Jeffrey Wang <jw...@palantir.com> wrote:
> Hey all,
>
>
>
> I've been seeing a very rare issue with schema change conflicts on 0.7.3 (I
> am serializing all schema changes to a single Cassandra node and waiting for
> them to finish before continuing). Occasionally a node in the cluster will
> never report the correct schema, and I think it may have to do with
> synchronization on DatabaseDescriptor.defsVersion.
>
>
>
> As far as I can tell, it is a static variable accessed by multiple threads
> but is not protected by synchronized/volatile. I was able to write a test in
> which one thread never reads the modification done by another thread (as is
> expected by an unsynchronized variable). Should this be fixed or is there a
> higher level reason this does not need to be synchronized (in which case I
> should continue looking for the reason why my schemas don't agree)? Thanks.
>
>
>
> -Jeffrey
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: DatabaseDescriptor.defsVersion
Posted by Jonathan Ellis <jb...@gmail.com>.
I think you found a bug; it should be volatile. (Cassandra does
already make sure that only one change runs internally at a time.)
Can you create a ticket?
On Fri, Apr 15, 2011 at 6:04 PM, Jeffrey Wang <jw...@palantir.com> wrote:
> Hey all,
>
>
>
> I’ve been seeing a very rare issue with schema change conflicts on 0.7.3 (I
> am serializing all schema changes to a single Cassandra node and waiting for
> them to finish before continuing). Occasionally a node in the cluster will
> never report the correct schema, and I think it may have to do with
> synchronization on DatabaseDescriptor.defsVersion.
>
>
>
> As far as I can tell, it is a static variable accessed by multiple threads
> but is not protected by synchronized/volatile. I was able to write a test in
> which one thread never reads the modification done by another thread (as is
> expected by an unsynchronized variable). Should this be fixed or is there a
> higher level reason this does not need to be synchronized (in which case I
> should continue looking for the reason why my schemas don’t agree)? Thanks.
>
>
>
> -Jeffrey
>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com