cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: The key list of multiget_slice's parameter has been changed unexpectedly.
Date Mon, 29 Nov 2010 12:18:31 GMT
You should start by trying 0.7 RC1. Some bugs with the use of
ByteBuffers have been corrected since beta2.

If you still have problem, then it's likely a bug, the byteBuffer
should not be changed from under you.
If it still doesn't work with RC1, it would be very helpful if you can
provide a simple script that reproduce the
behavior you describe.

On Mon, Nov 29, 2010 at 12:07 PM, eggli <> wrote:
> Hi everyone, we are working on a Java product based on Cassandra since 0.5, and Cassandra
made a very huge change in 0.7 beta 2, which changes all byte array into ByteBuffers, and
we found this problem which confuses us a lot, here's the detail about what happened:
> The multiget_slice method in Cassandra.Iface indicated that it requires a list of keys
for multi get slice query, which we believed we have to give every individual keys to get
the data we need, and according to the Java doc, we will get a Map result, which uses a  ByteBuffer
as key and ColunmOrSuperColumn as value, we made a guess that the ByteBuffer is the key we
send for query, in the case above, the result Map should looks like if we give a key list
<A,B,C> :
> Key of A -> Data of A
> Key of B -> Data of B
> Key of C -> Data of C
> In order to get Data of A from the result map, all we need to do is perform a resultMap.get(A),
but we got problem here: The result map's key is something else, it's not the key we gave
before, in the case above, it's no longer a list of <A,B,C> while the value is exactly
the data we need, but it's very troublesome we are unable to find the corresponding data from
the key.
> We made a guess that the key ByteBuffers has been changed in the query process due to
call by reference, and we found this in the server's source code which looks like that the
key has been changed unexpectedly in org.apache.cassandra.thrift.CassandraServer's getSlice
> columnFamilies.get(StorageService.getPartitioner().decorateKey(command.key));
> Looks like the key has been "decorated" for some purpose, and it's has been changed in
the process due to the nature of ByteBuffer, and the decorated key has been used as the key
in the result map.
> columnFamiliesMap.put(command.key, thriftifiedColumns);
> Are we misinterpreted the Java Doc API or is this is a bug?

View raw message