You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by David Hawthorne <dh...@3crowd.com> on 2011/03/29 21:16:58 UTC

client connection timeouts vs. thrift timeouts

I've been scratching my head on this one for a day now and I'm hoping someone can help clear it up.

The initial question was: does it make sense to have a configurable connection timeout (for a client connecting to a cassandra server) separate from the thrift socket timeout (which governs *all* interactions)?

The context is that I've written a java middleware (using hector with connection pooling, talking to a round-robin vip that will do healthchecking and will also need a connection timeout configured) for a php frontend to talk to, which sits between cassandra and the frontend.  I'd like to let the frontend know that the cassandra service is down fairly quickly so it can move on to other logic sooner rather than later, and I don't want it to have to wait however long I've set the thrift socket timeout to be.  The feedback I got initially was that I would run into problems with high load, and could run into delays when cassandra gets overwhelmed.

Does this make sense or am I just looking at this from the wrong angle?

Re: client connection timeouts vs. thrift timeouts

Posted by Narendra Sharma <na...@gmail.com>.
I think it make sense to have two different timeouts. The client timeout
clearly affects user's experience with the application. The timeout could be
due to number of factors not directly related to thrift connection. The
client timeout could trigger retry of operation on a different instance of
the application.

-Naren

On Tue, Mar 29, 2011 at 12:16 PM, David Hawthorne <dh...@3crowd.com> wrote:

> I've been scratching my head on this one for a day now and I'm hoping
> someone can help clear it up.
>
> The initial question was: does it make sense to have a configurable
> connection timeout (for a client connecting to a cassandra server) separate
> from the thrift socket timeout (which governs *all* interactions)?
>
> The context is that I've written a java middleware (using hector with
> connection pooling, talking to a round-robin vip that will do healthchecking
> and will also need a connection timeout configured) for a php frontend to
> talk to, which sits between cassandra and the frontend.  I'd like to let the
> frontend know that the cassandra service is down fairly quickly so it can
> move on to other logic sooner rather than later, and I don't want it to have
> to wait however long I've set the thrift socket timeout to be.  The feedback
> I got initially was that I would run into problems with high load, and could
> run into delays when cassandra gets overwhelmed.
>
> Does this make sense or am I just looking at this from the wrong angle?




-- 
Narendra Sharma
Solution Architect
*http://www.persistentsys.com*
*http://narendrasharma.blogspot.com/*