cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <>
Subject Re: Problems with subcolumn retrieval after upgrade from 0.6 to 0.7
Date Sat, 16 Apr 2011 23:38:46 GMT
Can you run the same request as a get_slice naming the column in the SlicePredicate and see
what comes back ? 

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

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


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:
> ERROR 12:56:05,669 Internal error processing get
> java.lang.AssertionError
>         at org.apache.cassandra.thrift.
> CassandraServer.get(
>         at org.apache.cassandra.thrift.Cassandra$Processor$get.process(
>         at org.apache.cassandra.thrift.Cassandra$Processor.process(
>         at org.apache.cassandra.thrift.CustomTThreadPoolServer$
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> 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.
> Abe Sanderson

View raw message