Ok, set up a unit test for the supercolumns which seem to have problems, I
posted a few examples below. As I mentioned, the retrieved bytes for the
name and value appear to have additional data; in previous tests the
buffer's position, mark, and limit have been verified, and when I call
column.getName(), just the bytes for the name itself are properly
retrieved(if not I should be getting validation errors for the custom uuid
types, correct?).
Abe Sanderson
get_slice for key: 80324d09-302b-4093-9708-e509091e5d8f supercolumn:
0faced00057372002a6c696e676f74656b2e646f6373746f72652e43617373616e647261446f63756d656e74245461726765749d0b9f071f4cb0410200024900076d5f70686173654c00066d5f6c616e677400124c6a6176612f6c616e672f537472696e673b78700000000174000564655f4445
subcolumn: [ cf="TranslationsByTarget"
name="78cfd525-a520-458e-8584-259415b88405"]
colParent:ColumnParent(column_family:TranslationsByTarget, super_column:0F
AC ED 00 05 73 72 00 2A 6C 69 6E 67 6F 74 65 6B 2E 64 6F 63 73 74 6F 72 65
2E 43 61 73 73 61 6E 64 72 61 44 6F 63 75 6D 65 6E 74 24 54 61 72 67 65 74
9D 0B 9F 07 1F 4C B0 41 02 00 02 49 00 07 6D 5F 70 68 61 73 65 4C 00 06 6D
5F 6C 61 6E 67 74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74 72 69 6E 67
3B 78 70 00 00 00 01 74 00 05 64 65 5F 44 45)
predicate:SlicePredicate(column_names:[java.nio.HeapByteBuffer[pos=0 lim=17
cap=17]])
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C 00 01 0B 00 01 00
00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60 63, value:80 01 00
02 00 00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00
04 0C 00 01 0B 00 01 00 00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF
6F 60 63 0B 00 02 00 00 00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC
40 7E, timestamp:1301327609539))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C 00 01 0B 00 01 00
00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60 63 0B 00 02 00 00
00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E 0A 00 03 00 00 01
2E FD 2B 7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78 CF D5 25 A5 20 45
8E 85 84 25 94 15 B8 84 05, value:80 01 00 02 00 00 00 09 67 65 74 5F 73 6C
69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C 00 01 0B 00 01 00 00 00 11
10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60 63 0B 00 02 00 00 00 11 10
FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E 0A 00 03 00 00 01 2E FD 2B
7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78 CF D5 25 A5 20 45 8E 85 84
25 94 15 B8 84 05 0B 00 02 00 00 00 11 10..., timestamp:1301327602293))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C 00 01 0B 00 01 00
00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60 63 0B 00 02 00 00
00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E 0A 00 03 00 00 01
2E FD 2B 7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78 CF D5 25 A5 20 45
8E 85 84 25 94 15 B8 84 05 0B 00 02 00 00 00 11 10..., value:80 01 00 02 00
00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C
00 01 0B 00 01 00 00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60
63 0B 00 02 00 00 00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E
0A 00 03 00 00 01 2E FD 2B 7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78
CF D5 25 A5 20 45 8E 85 84 25 94 15 B8 84 05 0B 00 02 00 00 00 11 10...,
timestamp:1301327589704))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C 00 01 0B 00 01 00
00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60 63 0B 00 02 00 00
00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E 0A 00 03 00 00 01
2E FD 2B 7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78 CF D5 25 A5 20 45
8E 85 84 25 94 15 B8 84 05 0B 00 02 00 00 00 11 10..., value:80 01 00 02 00
00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 04 0C
00 01 0B 00 01 00 00 00 11 10 49 5D 01 32 73 0D 48 03 85 09 CA F1 AF 6F 60
63 0B 00 02 00 00 00 11 10 FC 0A 0D 43 B1 E0 44 F9 96 AA FC EE 41 EC 40 7E
0A 00 03 00 00 01 2E FD 2B 7E C3 00 00 0C 00 01 0B 00 01 00 00 00 11 10 78
CF D5 25 A5 20 45 8E 85 84 25 94 15 B8 84 05 0B 00 02 00 00 00 11 10...,
timestamp:1301327594118))
get_slice for key: d1c7f6b9-1425-4fab-b074-5574c54cae08 supercolumn:
0faced00057372002a6c696e676f74656b2e646f6373746f72652e43617373616e647261446f63756d656e74245461726765749d0b9f071f4cb0410200024900076d5f70686173654c00066d5f6c616e677400124c6a6176612f6c616e672f537472696e673b78700000000174000564655f4445
subcolumn: [ cf="TranslationsByTarget"
name="b2f33b97-69f4-45ec-ad87-dd14ee60d719"]
colParent:ColumnParent(column_family:TranslationsByTarget, super_column:0F
AC ED 00 05 73 72 00 2A 6C 69 6E 67 6F 74 65 6B 2E 64 6F 63 73 74 6F 72 65
2E 43 61 73 73 61 6E 64 72 61 44 6F 63 75 6D 65 6E 74 24 54 61 72 67 65 74
9D 0B 9F 07 1F 4C B0 41 02 00 02 49 00 07 6D 5F 70 68 61 73 65 4C 00 06 6D
5F 6C 61 6E 67 74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74 72 69 6E 67
3B 78 70 00 00 00 01 74 00 05 64 65 5F 44 45)
predicate:SlicePredicate(column_names:[java.nio.HeapByteBuffer[pos=0 lim=17
cap=17]])
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 04 0F 00 00 0C 00 00 00 02 0C 00 01 0B 00 01 00
00 00 11 10 7C 2F 5D 5B B3 70 42 E1 A6 A2 77 FC 72 14 40 FE, value:80 01 00
02 00 00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 04 0F 00 00 0C 00 00 00
02 0C 00 01 0B 00 01 00 00 00 11 10 7C 2F 5D 5B B3 70 42 E1 A6 A2 77 FC 72
14 40 FE 0B 00 02 00 00 00 11 10 B4 64 74 19 F9 44 4E A3 A5 F9 06 32 67 DB
33 19, timestamp:1301324860465))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 04 0F 00 00 0C 00 00 00 02 0C 00 01 0B 00 01 00
00 00 11 10 7C 2F 5D 5B B3 70 42 E1 A6 A2 77 FC 72 14 40 FE 0B 00 02 00 00
00 11 10 B4 64 74 19 F9 44 4E A3 A5 F9 06 32 67 DB 33 19 0A 00 03 00 00 01
2E FD 01 8C 31 00 00 0C 00 01 0B 00 01 00 00 00 11 10 B2 F3 3B 97 69 F4 45
EC AD 87 DD 14 EE 60 D7 19, value:80 01 00 02 00 00 00 09 67 65 74 5F 73 6C
69 63 65 00 00 00 04 0F 00 00 0C 00 00 00 02 0C 00 01 0B 00 01 00 00 00 11
10 7C 2F 5D 5B B3 70 42 E1 A6 A2 77 FC 72 14 40 FE 0B 00 02 00 00 00 11 10
B4 64 74 19 F9 44 4E A3 A5 F9 06 32 67 DB 33 19 0A 00 03 00 00 01 2E FD 01
8C 31 00 00 0C 00 01 0B 00 01 00 00 00 11 10 B2 F3 3B 97 69 F4 45 EC AD 87
DD 14 EE 60 D7 19 0B 00 02 00 00 00 11 10..., timestamp:1301325719735))
get_slice for key: 18b4acd1-5491-44d3-aaa1-b725f51d1c3b supercolumn:
0faced00057372002a6c696e676f74656b2e646f6373746f72652e43617373616e647261446f63756d656e74245461726765749d0b9f071f4cb0410200024900076d5f70686173654c00066d5f6c616e677400124c6a6176612f6c616e672f537472696e673b787000000001740005706c5f504c
subcolumn: [ cf="TranslationsByTarget"
name="3da78c49-a8aa-4fdb-8238-1ade458426b5"]
colParent:ColumnParent(column_family:TranslationsByTarget, super_column:0F
AC ED 00 05 73 72 00 2A 6C 69 6E 67 6F 74 65 6B 2E 64 6F 63 73 74 6F 72 65
2E 43 61 73 73 61 6E 64 72 61 44 6F 63 75 6D 65 6E 74 24 54 61 72 67 65 74
9D 0B 9F 07 1F 4C B0 41 02 00 02 49 00 07 6D 5F 70 68 61 73 65 4C 00 06 6D
5F 6C 61 6E 67 74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74 72 69 6E 67
3B 78 70 00 00 00 01 74 00 05 70 6C 5F 50 4C)
predicate:SlicePredicate(column_names:[java.nio.HeapByteBuffer[pos=0 lim=17
cap=17]])
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 03 0C 00 01 0B 00 01 00
00 00 11 10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77 AF 2E BD, value:80 01 00
02 00 00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00
03 0C 00 01 0B 00 01 00 00 00 11 10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77
AF 2E BD 0B 00 02 00 00 00 11 10 62 58 73 23 CB 37 4F B5 BD DD BC F5 1E 7F
E7 65, timestamp:1301000346861))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 03 0C 00 01 0B 00 01 00
00 00 11 10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77 AF 2E BD 0B 00 02 00 00
00 11 10 62 58 73 23 CB 37 4F B5 BD DD BC F5 1E 7F E7 65 0A 00 03 00 00 01
2E E9 A9 DC ED 00 00 0C 00 01 0B 00 01 00 00 00 11 10 3D A7 8C 49 A8 AA 4F
DB 82 38 1A DE 45 84 26 B5, value:80 01 00 02 00 00 00 09 67 65 74 5F 73 6C
69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 03 0C 00 01 0B 00 01 00 00 00 11
10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77 AF 2E BD 0B 00 02 00 00 00 11 10
62 58 73 23 CB 37 4F B5 BD DD BC F5 1E 7F E7 65 0A 00 03 00 00 01 2E E9 A9
DC ED 00 00 0C 00 01 0B 00 01 00 00 00 11 10 3D A7 8C 49 A8 AA 4F DB 82 38
1A DE 45 84 26 B5 0B 00 02 00 00 00 11 10..., timestamp:1301000346885))
col: ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 09 67 65 74
5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 03 0C 00 01 0B 00 01 00
00 00 11 10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77 AF 2E BD 0B 00 02 00 00
00 11 10 62 58 73 23 CB 37 4F B5 BD DD BC F5 1E 7F E7 65 0A 00 03 00 00 01
2E E9 A9 DC ED 00 00 0C 00 01 0B 00 01 00 00 00 11 10 3D A7 8C 49 A8 AA 4F
DB 82 38 1A DE 45 84 26 B5 0B 00 02 00 00 00 11 10..., value:80 01 00 02 00
00 00 09 67 65 74 5F 73 6C 69 63 65 00 00 00 02 0F 00 00 0C 00 00 00 03 0C
00 01 0B 00 01 00 00 00 11 10 24 D4 2C 7F 2D C3 4A 80 B3 FF 5B A3 77 AF 2E
BD 0B 00 02 00 00 00 11 10 62 58 73 23 CB 37 4F B5 BD DD BC F5 1E 7F E7 65
0A 00 03 00 00 01 2E E9 A9 DC ED 00 00 0C 00 01 0B 00 01 00 00 00 11 10 3D
A7 8C 49 A8 AA 4F DB 82 38 1A DE 45 84 26 B5 0B 00 02 00 00 00 11 10...,
timestamp:1301000346836))
On Mon, Apr 18, 2011 at 5:41 PM, aaron morton <aa...@thelastpickle.com>wrote:
> Can you could provide an example of a get_slice request that failed and the
> columns that were returned, so we can see the actual bytes for the super
> column and column names.
>
> Aaron
>
>
> On 19 Apr 2011, at 09:26, Abraham Sanderson wrote:
>
> I wish it were consistent enough that the answer were simple... It varies
> between just the requested subcolumn to all subcolumns. It always does
> return the columns in order, and the requested column is always one of the
> columns returned. However, the slice start is not consistently in the same
> place(like n+1 or n-1). For example, if I have CF['key']['supercolumn'
> ['a','b','c','d','e']], and query for 'c', sometimes i get a slice with 'a',
> 'b', 'c', other times its 'b', 'c', 'd', sometimes 'c', 'd'. When the
> column name is closer to the end of the range('d' or 'e'), sometimes it
> justs a slice with the column. The sporadic behavior makes me think that
> it's a race condition, but the behavior linked to the column range makes we
> think I'm overrunning the buffer somewhere. I at first suspected that I was
> inadvertently making modifications to the buffers in application code during
> serialization/deserialization, so I did the tests in the cli. This limits
> it to just cassandra/thrift code and my custom types. Am I missing some
> other factor? While debugging I have noticed that the byte buffers contain
> more than they used to; it looks to me like tokens that contain parts of the
> thrift response. I'd see strings like
> "???get_slice???Foo??7c2f5d5b-b370-42e1-a6a2-77fc721440fe????" Is it
> possible that I am inadvertently using a reserved token or something on my
> supercolumn name and this is screwing with the slice command?
>
> Abe
>
> On Mon, Apr 18, 2011 at 2:55 PM, aaron morton <aa...@thelastpickle.com>wrote:
>
>> When you run the get_slice which columns are returned ?
>>
>>
>> Aaron
>>
>> On 19 Apr 2011, at 04:12, Abraham Sanderson wrote:
>>
>> Ok, I made the changes and tried again. Here is the before modifying my
>> method using a simple get, confirmed the same output in the cli:
>>
>> DEBUG [pool-1-thread-2] 2011-04-18 09:37:23,910 CassandraServer.java (line
>> 279) get
>> DEBUG [pool-1-thread-2] 2011-04-18 09:37:23,911 StorageProxy.java (line
>> 322) Command/ConsistencyLevel is SliceByNamesReadCommand(table='DocStore',
>> key=64316337663662392d313432352d346661622d623037342d353537346335346361653038,
>> columnParent='QueryPath(columnFamilyName='Tran
>> slationsByTarget', superColumnName='java.nio.HeapByteBuffer[pos=95 lim=211
>> cap=244]', columnName='null')',
>> columns=[7c2f5d5b-b370-42e1-a6a2-77fc721440fe,])/ALL
>> DEBUG [pool-1-thread-2] 2011-04-18 09:37:23,911 ReadCallback.java (line
>> 84) Blockfor/repair is 1/true; setting up requests to localhost/127.0.0.1
>> DEBUG [pool-1-thread-2] 2011-04-18 09:37:23,911 StorageProxy.java (line
>> 345) reading data locally
>> DEBUG [ReadStage:4] 2011-04-18 09:37:23,911 StorageProxy.java (line 450)
>> LocalReadRunnable reading SliceByNamesReadCommand(table='DocStore',
>> key=64316337663662392d313432352d346661622d623037342d353537346335346361653038,
>> columnParent='QueryPath(columnFamilyName='Translatio
>> nsByTarget', superColumnName='java.nio.HeapByteBuffer[pos=95 lim=211
>> cap=244]', columnName='null')',
>> columns=[7c2f5d5b-b370-42e1-a6a2-77fc721440fe,])
>> DEBUG [pool-1-thread-2] 2011-04-18 09:37:23,912 StorageProxy.java (line
>> 395) Read: 1 ms.
>> ERROR [pool-1-thread-2] 2011-04-18 09:37:23,912 Cassandra.java (line 2665)
>> 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)
>>
>> And here is the after...it succeeds here but still gives me multiple
>> subcolumns in the response. Same behavior, it seems, I'm just sidestepping
>> the original AssertionError:
>>
>> DEBUG [pool-1-thread-6] 2011-04-18 09:50:26,617 CassandraServer.java (line
>> 232) get_slice
>> DEBUG [pool-1-thread-6] 2011-04-18 09:50:26,617 StorageProxy.java (line
>> 322) Command/ConsistencyLevel is SliceByNamesReadCommand(table='DocStore',
>> key=64316337663662392d313432352d346661622d623037342d353537346335346361653038,
>> columnParent='QueryPath(columnFamilyName='TranslationsByTarget',
>> superColumnName='java.nio.HeapByteBuffer[pos=101 lim=217 cap=259]',
>> columnName='null')', columns=[7c2f5d5b-b370-42e1-a6a2-77fc721440fe,])/ALL
>> DEBUG [pool-1-thread-6] 2011-04-18 09:50:26,617 ReadCallback.java (line
>> 84) Blockfor/repair is 1/true; setting up requests to localhost/127.0.0.1
>> DEBUG [pool-1-thread-6] 2011-04-18 09:50:26,617 StorageProxy.java (line
>> 345) reading data locally
>> DEBUG [ReadStage:3] 2011-04-18 09:50:26,618 StorageProxy.java (line 450)
>> LocalReadRunnable reading SliceByNamesReadCommand(table='DocStore',
>> key=64316337663662392d313432352d346661622d623037342d353537346335346361653038,
>> columnParent='QueryPath(columnFamilyName='TranslationsByTarget',
>> superColumnName='java.nio.HeapByteBuffer[pos=101 lim=217 cap=259]',
>> columnName='null')', columns=[7c2f5d5b-b370-42e1-a6a2-77fc721440fe,])
>> DEBUG [pool-1-thread-6] 2011-04-18 09:50:26,618 StorageProxy.java (line
>> 395) Read: 0 ms.
>>
>> My comparators are relatively simple. Basically I have a schema that
>> required heterogenous columns, but I needed to be able to deserialize them
>> in unique ways. So there is always a type byte that precedes the bytes of
>> the data. The supercolumn in this case is a general data type, which
>> happens to represent a serializable object:
>>
>> public void validate(ByteBuffer bytes)
>> throws MarshalException
>> {
>> if(bytes.remaining() == 0)
>> return;
>>
>> validateDataType(bytes.get(bytes.position()));
>> return;
>> }
>>
>> public int compare(ByteBuffer bytes1, ByteBuffer bytes2)
>> {
>> if (bytes1.remaining() == 0)
>> return bytes2.remaining() == 0 ? 0 : -1;
>> else if (bytes2.remaining() == 0)
>> return 1;
>> else
>> {
>> // compare type
>> bytes
>>
>> byte T1 = bytes1.get(bytes1.position());
>> byte T2 = bytes2.get(bytes2.position());
>> if (T1 != T2)
>> return (T1 - T2);
>>
>> // compare
>> values
>>
>> return ByteBufferUtil.compareUnsigned(bytes1, bytes2);
>> }
>> }
>>
>> The subcolumn is similar...just a UUID with a type byte prefix:
>>
>> public void validate(ByteBuffer bytes)
>> throws MarshalException
>> {
>> if(bytes.remaining() == 0)
>> return;
>>
>> validateDataType(bytes.get(bytes.position()));
>> if((bytes.remaining() - 1) == 0)
>> return;
>> else if((bytes.remaining() - 1) != 16)
>> throw new MarshalException("UUID value must be exactly 16 bytes");
>> }
>>
>> public int compare(ByteBuffer bytes1, ByteBuffer bytes2)
>> {
>> if (bytes1.remaining() == 0)
>> return bytes2.remaining() == 0 ? 0 : -1;
>> else if (bytes2.remaining() == 0)
>> return 1;
>> else
>> {
>> // compare type
>> bytes
>>
>> byte T1 = bytes1.get(bytes1.position());
>> byte T2 = bytes2.get(bytes2.position());
>> if (T1 != T2)
>> return (T1 - T2);
>>
>> // compare
>> values
>>
>> UUID U1 = getUUID(bytes1, bytes1.position()+1);
>> UUID U2 = getUUID(bytes2, bytes2.position()+1);
>> return U1.compareTo(U2);
>> }
>> }
>>
>> static UUID getUUID(ByteBuffer bytes, int pos)
>> {
>> long msBits = bytes.getLong(pos);
>> long lsBits = bytes.getLong(pos+8);
>> return new UUID(msBits, lsBits);
>> }
>>
>> All of my buffer reads are done by index, the position shouldn't be
>> changing at all.
>>
>> Abe Sanderson
>>
>> On Sat, Apr 16, 2011 at 5:38 PM, aaron morton <aa...@thelastpickle.com>wrote:
>>
>>> 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
>>>
>>>
>>
>>
>
>
