cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Narendra Sharma <>
Subject Re: client connection timeouts vs. thrift timeouts
Date Tue, 29 Mar 2011 20:46:50 GMT
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.


On Tue, Mar 29, 2011 at 12:16 PM, David Hawthorne <> 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

View raw message