The key list of multiget_slice's parameter has been changed unexpectedly.

[eggli <ae...@gmail.com>]

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 method:

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?

Re: The key list of multiget_slice's parameter has been changed unexpectedly.

[Sylvain Lebresne <sy...@yakaz.com>]

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 <ae...@gmail.com> 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 method:
>
> 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?
>