cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arya Goudarzi <agouda...@gaiaonline.com>
Subject Re: Question regarding Client.set_keyspace(String)
Date Wed, 03 Nov 2010 01:59:15 GMT
1. yes
2. I wondered about the same question a while back and I ended up here : http://www.mail-archive.com/cassandra-commits@incubator.apache.org/msg07761.html

In summary the reason is per keyspace authentication.

----- Original Message -----
From: "Dan Washusen" <dan@reactive.org>
To: client-dev@cassandra.apache.org
Sent: Tuesday, November 2, 2010 5:55:49 PM
Subject: Re: Question regarding Client.set_keyspace(String)

Thanks for the response Arya.  Maybe I should clarify my questions....

   1. Does the call to Client.set_keyspace(String) really do a
   server/network round trip every time it's invoked?
   2. If yes to question 1, does the Client.set_keyspace(String) call really
   need to do a server/network round trip every time it's called (e.g. couldn't
   the validation be deferred until the client attempts to do something against
   the keyspace)?

After a little more digging it appears that the client's keyspace state is
actaully saved on the cassandra node that it's connected to and not on the
client itself.  That appears to explain why it's necessary to do a network
call each time the Client.set_keyspace(String) method is called...

Cheers,
Dan

On Wed, Nov 3, 2010 at 11:40 AM, Arya Goudarzi <agoudarzi@gaiaonline.com>wrote:

> If your client needs to support working with different keyspaces at that
> same time, then you need to have a mechanism to call set_keyspace() per
> operation. In your connection pool you can have something like getClient()
> which selects a node from the pool from your operation during a client
> session. In there you can call set_keyspace() and upon success, save the
> keyspace name in some local flag and next time you want to get the same
> client if the local flag has the same keyspace then you won't call
> set_keyssapce(). This is only if you want to work with multiple keyspaces in
> one session. Otherwise, you can only set_keysapce() once you get a node for
> operations like pycassa.
>
> ----- Original Message -----
> From: "Dan Washusen" <dan@reactive.org>
> To: client-dev@cassandra.apache.org
> Sent: Tuesday, November 2, 2010 5:24:17 PM
> Subject: Question regarding Client.set_keyspace(String)
>
> Hey All,
> It looks like the Client.set_keyspace method does a server round trip to
> validate that the keyspace exists.
>
> Exhibit A:
>
> > InvalidRequestException(why:Keyspace does not exist)
> >
> > at
> >>
> org.apache.cassandra.thrift.Cassandra$set_keyspace_result.read(Cassandra.java:4816)
> >
> > at
> >>
> org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:451)
> >
> > at
> >>
> org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:426)
> >
> >
> I was looking into making a connection pool that is independent of a
> keyspace.   My thinking is that a connection pool is relatively expensive
> and if a user has more than one keyspace, it would be ideal to maintain a
> single pool for the cluster rather than one per keyspace.
>
> My plan was going to defer the Client.set_keyspace(String) call from the
> point that the connection is initialised, to the point that the connection
> is borrowed from the pool.  However, if that call requires a server round
> trip it might do more harm that good...
>
> Two questions;
>
>    1. Does the call to Client.set_keyspace(String) really do a server round
>    trip every time it's invoked?
>    2. If yes, is it really necessary?
>
> Cheers,
> Dan
>

Mime
View raw message