Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 sylvain@yakaz.com does not designate 209.85.212.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <48EBF39C-FF3F-43C0-BFAD-4E5325388413@gmail.com>
References: <48EBF39C-FF3F-43C0-BFAD-4E5325388413@gmail.com>
From: Sylvain Lebresne <sylvain@yakaz.com>
Date: Mon, 29 Nov 2010 13:18:31 +0100
Message-ID: <AANLkTikx+WJywAt9MwEkc3+007oNOvvXyjN_afCYct6Y@mail.gmail.com>
Subject: Re: The key list of multiget_slice's parameter has been changed
 unexpectedly.
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <aeggli@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 b=
yte array into ByteBuffers, and we found this problem which confuses us a l=
ot, 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 do=
c, we will get a Map result, which uses a =A0ByteBuffer as key and ColunmOr=
SuperColumn as value, we made a guess that the ByteBuffer is the key we sen=
d 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 perfo=
rm a resultMap.get(A), but we got problem here: The result map's key is som=
ething else, it's not the key we gave before, in the case above, it's no lo=
nger 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 ke=
y.
>
> We made a guess that the key ByteBuffers has been changed in the query pr=
ocess due to call by reference, and we found this in the server's source co=
de which looks like that the key has been changed unexpectedly in org.apach=
e.cassandra.thrift.CassandraServer's getSlice method:
>
> columnFamilies.get(StorageService.getPartitioner().decorateKey(command.ke=
y));
>
> Looks like the key has been "decorated" for some purpose, and it's has be=
en changed in the process due to the nature of ByteBuffer, and the decorate=
d 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?
>