hi guys, thanks for the feedback. yet another rails issue that makes deployment a hassle. my biggest issue with setting the timeouts is that when a user hits the page after a timeout, they will get a 5xx error, but perhaps i can teach rails to catch the exception and retry the connection. anyway, thanks for clarifying that i wasn't missing some simple config option.
...gg On Thu, Feb 25, 2010 at 6:24 PM, Willy Tarreau <[email protected]> wrote: > Hi, > > On Thu, Feb 25, 2010 at 10:54:35PM +0100, XANi wrote: >> Dnia 2010-02-25, czw o godzinie 16:27 -0500, Greg Gard pisze: >> >> > hi willy and friends, >> > >> > i am working on a set of ruby scripts to do database failover and >> > stonith. so far all is working pretty well, but i have a few issues: >> > >> > 1) rails makes persistent connections to the backend database so when >> > a server is marked down, the connection remains ongoing. currently, i >> > deal with this by issuing a "stonith" command in my ruby "driver" >> > script for haproxy that shuts the backend down explicitly via ssh, but >> > it would be nice if i could rely on haproxy to kill the connection >> > explicitly. is there a setting to make haproxy kill existing >> > connections on a backend going down? >> > >> > 2) for rails i have tcp timeout set to 0 so it seems to be handling >> > the persistent connections ok, but when i do a reload using the >> > haproxy init script in the debian packages, i end up with two haproxy >> > backends as the persistent connections aren't killed. essentially the >> > original process is waiting for the connections to end before it kills >> > itself, but that will never happen with rails db connection. any ideas >> > or suggestions? >> > >> > ps: having rails not use persistent connections is not really what i >> > would like to do right now. i have run that in the past on production >> > and had wierd timeout problems and choppy connectivity. >> > >> > thanks...gg >> > >> >> >> 1) If i remember correctly client/server timeouts only trigger when >> there is no activity (no data send) so setting client and server timeout >> to like 5 min could solve problem >> so as long as app do some queries connection won't be dropped > > Exactly. It is wrong to set infinite timeouts, it will always cause > trouble. Still we see people using them from time to time, despite > the huge annoying warning upon config reload. > >> 2) u can do "/etc/init.d/haproxy stop ; /etc/init.d/haproxy start" > > The correct timeout will also take care of that because the connections > will eventually die and the old process exit. > > This situation is the perfect illustration of why it's wrong to run > with no timeouts. > > Regards, > Willy > > -- greg gard, psyd www.carepaths.com
