Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=content-type
	:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to; q=dns; s=
	thelastpickle.com; b=u1NqsiZ3qRdJTYKXcDAXWSXEjfUGSiomBsNp092lu33
	1BvrCceKZYooK941tL+IwsRitEg6ttwPGrbRtqCuSeCuw9tFfUw/al6HDrfs8fDh
	Z9qkI6mP8bnJsXyZpzAZh5zYxgXQswoebvCSl6UGbJ2u6s2fCaTE/5BnRUahKA68
	=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Problems with subcolumn retrieval after upgrade from 0.6 to 0.7
From: aaron morton <aaron@thelastpickle.com>
In-Reply-To: <BANLkTi=eBXfdOQZCYCmM_V8NKuhCCskRMw@mail.gmail.com>
Date: Sun, 17 Apr 2011 11:38:46 +1200
Content-Transfer-Encoding: quoted-printable
Message-Id: <56163278-BEDC-4D1E-A7E8-0D8DBA86C332@thelastpickle.com>
References: <BANLkTi=eBXfdOQZCYCmM_V8NKuhCCskRMw@mail.gmail.com>
To: user@cassandra.apache.org

Can you run the same request as a get_slice naming the column in the =
SlicePredicate and see what comes back ?=20

Can you reproduce the fault with logging set at DEBUG and send the logs =
?

Also, whats the compare function like for your custom type ?

Cheers
Aaron

=20
On 16 Apr 2011, at 07:34, Abraham Sanderson wrote:

> I'm having some issues with a few of my ColumnFamilies after a =
cassandra upgrade/import from 0.6.1 to 0.7.4.  I followed the =
instructions to upgrade and everything seem to work OK...until I got =
into the application and noticed some wierd behavior.  I was getting the =
following stacktrace in cassandra occassionally when I did get =
operations for a single subcolumn for some of the Super type CFs:
>=20
> ERROR 12:56:05,669 Internal error processing get
> java.lang.AssertionError
>         at org.apache.cassandra.thrift.
> CassandraServer.get(CassandraServer.java:300)
>         at =
org.apache.cassandra.thrift.Cassandra$Processor$get.process(Cassandra.java=
:2655)
>         at =
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:255=
5)
>         at =
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(Cust=
omTThreadPoolServer.java:206)
>         at =
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:=
1110)
>         at =
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java=
:603)
>         at java.lang.Thread.run(Thread.java:636)
>=20
> The assertion that is failing is the check that only one column is =
retrieved by the get.  I did some debugging with the cli and a remote  =
debugger and found a few interesting patterns.  First, the problem does =
not seem consistently duplicatable.  If one supercolumn is affected =
though, it will happen more frequently for subcolumns that when sorted =
appear at the beginning of the range.  For columns near the end of the =
range, it seems to be more intermittent, and almost never occurs when I =
step through the code line by line.  The only factor I can think of that =
might cause issues is that I am using custom data types for all =
supercolumns and columns.  I originally thought I might be reading past =
the end of the ByteBuffer, but I have quadrupled checked that this is =
not the case.
>=20
> Abe Sanderson