Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 32505 invoked from network); 15 Apr 2011 23:33:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Apr 2011 23:33:13 -0000 Received: (qmail 63125 invoked by uid 500); 15 Apr 2011 23:05:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 63100 invoked by uid 500); 15 Apr 2011 23:05:11 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 63092 invoked by uid 99); 15 Apr 2011 23:05:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 23:05:11 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jwang@palantir.com designates 206.188.26.34 as permitted sender) Received: from [206.188.26.34] (HELO mx2.palantir.com) (206.188.26.34) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 23:05:04 +0000 Received: from pa-ex-01.YOJOE.local (10.160.10.13) by sj-ex-cas-01.YOJOE.local (10.160.10.12) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 15 Apr 2011 16:04:43 -0700 Received: from pa-ex-01.YOJOE.local ([10.160.10.13]) by pa-ex-01.YOJOE.local ([10.160.10.13]) with mapi; Fri, 15 Apr 2011 16:04:43 -0700 From: Jeffrey Wang To: "user@cassandra.apache.org" Date: Fri, 15 Apr 2011 16:04:40 -0700 Subject: DatabaseDescriptor.defsVersion Thread-Topic: DatabaseDescriptor.defsVersion Thread-Index: Acv7wX/kChytVGgrQSm7es1BdzEGoA== Message-ID: <5FAFCB6230A1754CBC58296E62D8D5E602FBC40358@pa-ex-01.YOJOE.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Afym A4AH BVIM BcH2 BvrR ChvA EDZD EgYJ G1Qr G6Ex HO/C HWxH IOu/ IzWa KEHV KwP9;1;dQBzAGUAcgBAAGMAYQBzAHMAYQBuAGQAcgBhAC4AYQBwAGEAYwBoAGUALgBvAHIAZwA=;Sosha1_v1;7;{8330B253-CB80-4837-B6E5-1A209016B343};agB3AGEAbgBnAEAAcABhAGwAYQBuAHQAaQByAC4AYwBvAG0A;Fri, 15 Apr 2011 23:04:40 GMT;RABhAHQAYQBiAGEAcwBlAEQAZQBzAGMAcgBpAHAAdABvAHIALgBkAGUAZgBzAFYAZQByAHMAaQBvAG4A x-cr-puzzleid: {8330B253-CB80-4837-B6E5-1A209016B343} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5FAFCB6230A1754CBC58296E62D8D5E602FBC40358paex01YOJOElo_" MIME-Version: 1.0 --_000_5FAFCB6230A1754CBC58296E62D8D5E602FBC40358paex01YOJOElo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 f= or them to finish before continuing). Occasionally a node in the cluster wi= ll never report the correct schema, and I think it may have to do with sync= hronization 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 i= n which one thread never reads the modification done by another thread (as = is expected by an unsynchronized variable). Should this be fixed or is ther= e a higher level reason this does not need to be synchronized (in which cas= e I should continue looking for the reason why my schemas don't agree)? Tha= nks. -Jeffrey --_000_5FAFCB6230A1754CBC58296E62D8D5E602FBC40358paex01YOJOElo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey all,

IR= 17;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 w= ill never report the correct schema, and I think it may have to do with syn= chronization on DatabaseDescriptor.defsVersion.

As far as I can tell, it = is a static variable accessed by multiple threads but is not protected by s= ynchronized/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 unsynch= ronized variable). Should this be fixed or is there a higher level reason t= his does not need to be synchronized (in which case I should continue looki= ng for the reason why my schemas don’t agree)? Thanks.

-Jeffrey

= --_000_5FAFCB6230A1754CBC58296E62D8D5E602FBC40358paex01YOJOElo_--