From user-return-17066-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed May 25 04:08:32 2011 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C256143A8 for ; Wed, 25 May 2011 04:08:32 +0000 (UTC) Received: (qmail 60384 invoked by uid 500); 25 May 2011 04:08:30 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 60012 invoked by uid 500); 25 May 2011 04:08:29 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 59996 invoked by uid 99); 25 May 2011 04:08:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 May 2011 04:08:27 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a41.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 May 2011 04:08:19 +0000 Received: from homiemail-a41.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a41.g.dreamhost.com (Postfix) with ESMTP id 9182744C062 for ; Tue, 24 May 2011 21:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=to:from :subject:date:message-id:content-type:mime-version:in-reply-to; q=dns; s=thelastpickle.com; b=bxQVJmNWeKqrjUGcNDUN2vH4bUF9ndeID S64b44HTHs/4V3oIPpPBWKvHOzJVYNiLiLPhkmQzGKPOxRqSeqBOIJPXPuHQW/Ep IK2BYFBtIjAblE7tjWOtXJFsdwX6RBXkc+QsmLNPQiNaPAKyslnFJPbY2YsrSd3A IZLzQur5OY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=to :from:subject:date:message-id:content-type:mime-version: in-reply-to; s=thelastpickle.com; bh=aCLGB/LMUFNxxpFPfThTKJBgcz0 =; b=hlghXEXEoXi4LPCQqgT3qsa8YYMxq3gfWITY9fB3+BFb7b7cRxKVbfAIVEO TR/y9KKd7/hwsBJPVx3zNm3nQzvLXSMRmp6EzB5jeElzKFj6a3S6RzAF1mPM3XEn XyF/tE8emCI/1R1V5Qf110QWblyzaz9+md19g9LG5mmsE1JE= Received: from localhost (webms.mac.com [17.148.16.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a41.g.dreamhost.com (Postfix) with ESMTPSA id 8194D44C057 for ; Tue, 24 May 2011 21:07:52 -0700 (PDT) To: user@cassandra.apache.org From: Aaron Morton Subject: Re: How to make use of Cassandra raw row keys? Date: Wed, 25 May 2011 04:07:50 GMT X-Mailer: MobileMe Mail (1C3224) Message-id: <902f28d5-9341-6b1f-c995-8113aead8dea@me.com> Content-Type: multipart/alternative; boundary=Apple-Webmail-42--7199cdd4-5529-6241-f153-846bb632170e MIME-Version: 1.0 In-Reply-To: X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Webmail-42--7199cdd4-5529-6241-f153-846bb632170e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed The key printed in the DEBUG message is the byte array the server was give= n as the key converted to hex. Your client API may have converted the stri= ng to ascii bytes before sending to the server.=0A=0Ae.g. here is me writi= ng a 'foo' key to the server=A0=0ADEBUG 15:52:15,818 insert writing local = RowMutation(keyspace=3D'dev', key=3D'666f6f', modifications=3D[data])=0A=0A= =0AYou can tell the CLI what data type the keys are, see the assume statem= ent. e.g. assume my_cf keys as ascii; Will tell the cli to convert them ba= ck to ascii for you.=0A=0AHope that helps.=A0=0A-----------------=0AAaron = Morton=0AFreelance Cassandra Developer=0A@aaronmorton=0Ahttp://www.thelast= pickle.com=0A=0AOn 25 May, 2011,at 03:17 PM, Suan Aik Yeo wrote:=0A=0AWe're using Cassandra to store our sessions, all in a s= ingle column family "Sessions" with the format:=0ASessions['session_key'] = =3D {'val': }=0A(session_key is a randomly generated hash)=0A= =0AThe "raw" keys I'm talking about are for example the 'key' value as see= n from Cassandra DEBUG output:=0Ainsert writing local RowMutation(keyspace= =3D'my_keyspace', key=3D'73657373696f6e3a636561376532393135383861643734373= 2363130646163666331643161393334', modifications=3D[Sessions])=0A=0AToday w= e ran into a problem where a session with a given key (say "session:12345"= ) seemingly disappeared (at least it appeared that way to the client app),= but in the server log DEBUG output, the "raw" Cassandra key that seemed t= o correspond to that session_key (say "a12345f") was still being used as e= videnced by DEBUG log output. Indeed, none of the existing session_keys co= rresponded to the "a12345f" raw key. However, in Cassandra-cli when I do t= he "list Sessions" command, the "a12345f" raw key shows up as part of the = output.=0A=0AI'd like to dig further into the issue, but first I need to f= ind out:=0Awhat are these keys and how are they determined?=0AIs there any= way I could use them in querying Cassandra to find out what they're point= ing to? (Seems that even the cli expects the "session:12345" type key rath= er than raw ones when querying)=0A=0A=0AThanks,=0ASuan --Apple-Webmail-42--7199cdd4-5529-6241-f153-846bb632170e Content-Type: multipart/related; type="text/html"; boundary=Apple-Webmail-86--7199cdd4-5529-6241-f153-846bb632170e --Apple-Webmail-86--7199cdd4-5529-6241-f153-846bb632170e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1;
The key printed in the DEBUG message is the byte array the server was= given as the key converted to hex. Your client API may have converted the= string to ascii bytes before sending to the server.

<= div>e.g. here is me writing a 'foo' key to the server 
DEBUG 15:52:15,818 insert writing local RowMutation(keyspace=3D'dev', key= =3D'666f6f', modifications=3D[data])


You can tell the CLI what data type the keys are, see the assume = statement. e.g. assume my_cf keys as ascii; Will tell the cli to convert t= hem back to ascii for you.

Hope that helps. =
-----------------=0AAaron Morton=0AFreelance Cassandra Developer=0A=
@aaronmorton=0Ahttp://www.thelastpickle.com

On 25 May,= 2011,at 03:17 PM, Suan Aik Yeo <yeosuanaik@gmail.com> wrote:
We're = using Cassandra to store our sessions, all in a single column family "Sess= ions" with the format:
Sessions['session_key'] =3D {'val': <a= ctual_value>}
(session_key is a randomly generated hash)=0A

The "raw" keys I'm talking about are for example t= he 'key' value as seen from Cassandra DEBUG output:
insert writin= g local RowMutation(keyspace=3D'my_keyspace', key=3D'73657373696f6e3a63656= 13765323931353838616437343732363130646163666331643161393334', modification= s=3D[Sessions])
=0A

Today we ran into = a problem where a session with a given key (say "session:12345") seemingly= disappeared (at least it appeared that way to the client app), but in the= server log DEBUG output, the "raw" Cassandra key that seemed to correspon= d to that session_key (say "a12345f") was still being used as evidenced by= DEBUG log output. Indeed, none of the existing session_keys corresponded = to the "a12345f" raw key. However, in Cassandra-cli when I do the "list Se= ssions" command, the "a12345f" raw key shows up as part of the output.=0A

I'd like to dig further into the issue, but first= I need to find out:
what are these keys and how are they determ= ined?
Is there any way I could use them in querying Cassandra to= find out what they're pointing to? (Seems that even the cli expects the "= session:12345" type key rather than raw ones when querying)
=0A
<= br>

Thanks,
Suan
=0A
--Apple-Webmail-86--7199cdd4-5529-6241-f153-846bb632170e-- --Apple-Webmail-42--7199cdd4-5529-6241-f153-846bb632170e--