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 aeg...@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?
