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
