Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 80540 invoked from network); 1 Feb 2011 17:30:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Feb 2011 17:30:41 -0000 Received: (qmail 8370 invoked by uid 500); 1 Feb 2011 17:30:38 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 8305 invoked by uid 500); 1 Feb 2011 17:30:37 -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 8292 invoked by uid 99); 1 Feb 2011 17:30:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Feb 2011 17:30:36 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of roshandawrani@gmail.com designates 209.85.215.44 as permitted sender) Received: from [209.85.215.44] (HELO mail-ew0-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Feb 2011 17:30:28 +0000 Received: by ewy8 with SMTP id 8so3612562ewy.31 for ; Tue, 01 Feb 2011 09:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=665Ha03speU/1p6UeTanqu+phK5e+1IAqF8vvKzurxM=; b=JBAkYy/AQtNXF3zfJ2N4R86D1zTAM+2Zh0gwTdAayb4MqryV23c1ZZzTU5Jvb/WzXx trcPwkyg3qKcEf25Q02FEHLFTfrf36s2KcEwxYgREfjgSF1l5lgIU7zg+WFSSxoEpZ64 9NlIWIQ/9Boz1Ahj2vHswbX1kiTmpP/EugCsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EOQ8oXKlqv+/L2B+Zk0BUmZroaRWu/G3szINfgTEQPmk7v3RoUL4mextK3ZFkzIcFh +NCdi99hFOZidVlyMD9o3OqWFL1nN3AI0F0Hmkzx7Oa0PiWlf161FISJ5YBvGudvtqeo 3TfBb83NoGpi6qklYGM3oices53DTotyIsW2A= MIME-Version: 1.0 Received: by 10.216.208.230 with SMTP id q80mr885218weo.103.1296581408143; Tue, 01 Feb 2011 09:30:08 -0800 (PST) Received: by 10.216.0.77 with HTTP; Tue, 1 Feb 2011 09:30:08 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 23:00:08 +0530 Message-ID: Subject: Re: cassandra as session store From: Roshan Dawrani To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016e6d785a5413a18049b3be230 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6d785a5413a18049b3be230 Content-Type: text/plain; charset=ISO-8859-1 Please do keep this discussion on the mailing list and not take it offline. :-) I will be in the same boat very soon, I think. It will be great to hear from people who have already gone down this road and used Cassandra as a session store in a clustered environment. On Tue, Feb 1, 2011 at 10:56 PM, Kallin Nagelberg < kallin.nagelberg@gmail.com> wrote: > Cool, maybe we can help each other out. I'm using multiple web-apps, > all running in Resin containers. Have you thought about schema or how > to generate sessionIds for cookies? > > -Kal > > On Tue, Feb 1, 2011 at 12:22 PM, Sasha Dolgy wrote: > > I am working on this tonight with jetty as front end and cassandra as > > backend session store. Hopefully. > > > > On 1 Feb 2011 18:19, "Kallin Nagelberg" > wrote: > >> Hey, > >> I am currently investigating Cassandra for storing what are > >> effectively web sessions. Our production environment has about 10 high > >> end servers behind a load balancer, and we'd like to add distributed > >> session support. My main concerns are performance, consistency, and > >> the ability to create unique session keys. The last thing we would > >> want is users picking up each others sessions. After spending a few > >> days investigating Cassandra I'm thinking of creating a single > >> keyspace with a single super-column-family. The scf would store a few > >> standard columns, and a supercolumn of arbitrary session attributes, > >> like: > >> > >> 0s809sdf8s908sf90s: { > >> prop1: x, > >> created : timestamp, > >> lastAccessed: timestamp, > >> prop2: y, > >> arbirtraryProperties : { > >> someRandomProperty1:xxyyzz, > >> someRandomProperty2:xxyyzz, > >> someRandomProperty3:xxyyzz > >> } > >> > >> Does this sound like a reasonable use case? We are on a tight timeline > >> and I'm currently on the fence about getting something up and running > >> like this on a tight timeline. > >> > >> Thanks, > >> -Kal > > > --0016e6d785a5413a18049b3be230 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please do keep this discussion on the mailing list and not take it offline.= :-)

I will be in the same boat very soon, I think.

It will be great to hear from people who have already = gone down this road and used Cassandra as a session store in a clustered en= vironment.

On Tue, Feb 1, 2011 at 10:56 PM, Kallin Nage= lberg <k= allin.nagelberg@gmail.com> wrote:
Cool, maybe we can help each other out. I'm using multiple web-apps, all running in Resin containers. Have you thought about schema or how
to generate sessionIds for cookies?

-Kal

On Tue, Feb 1, 2011 at 12:22 PM, Sasha Dolgy <sdolgy@gmail.com> wrote:
> I am working on this tonight with jetty as front end and cassandra as<= br> > backend session store.=A0 Hopefully.
>
> On 1 Feb 2011 18:19, "Kallin Nagelberg" <kallin.nagelberg@gmail.com> wrote:
>> Hey,
>> I am currently investigating Cassandra for storing what are
>> effectively web sessions. Our production environment has about 10 = high
>> end servers behind a load balancer, and we'd like to add distr= ibuted
>> session support. My main concerns are performance, consistency, an= d
>> the ability to create unique session keys. The last thing we would=
>> want is users picking up each others sessions. After spending a fe= w
>> days investigating Cassandra I'm thinking of creating a single=
>> keyspace with a single super-column-family. The scf would store a = few
>> standard columns, and a supercolumn of arbitrary session attribute= s,
>> like:
>>
>> 0s809sdf8s908sf90s: {
>> prop1: x,
>> created : timestamp,
>> lastAccessed: timestamp,
>> prop2: y,
>> arbirtraryProperties : {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty1:xxyyzz,
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty2:xxyyzz,
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty3:xxyyzz
>> }
>>
>> Does this sound like a reasonable use case? We are on a tight time= line
>> and I'm currently on the fence about getting something up and = running
>> like this on a tight timeline.
>>
>> Thanks,
>> -Kal
>

--0016e6d785a5413a18049b3be230--