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? >
