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 ? Cheers Aaron 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(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:2555) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.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) > > 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
