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 <dha...@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/*
