On Fri, 2008-10-24 at 15:19 +0300, Ryan Murray wrote: > > > > ----- Original Message ---- > > From: André Warnier <aw@xxxxxxxxxx> > > To: users@xxxxxxxxxxxxxxxx > > Sent: Friday, October 24, 2008 2:42:58 AM > > Subject: Re: change BalancerMember status if servlet fails > > > > Chris Kemper wrote: > > [...] > > > > > > > > My question: If the servlet fails (e.g. returns a 50x http error), is > > there some way I can use that to set the corresponding BalanceMember > > status to Err or Dis? Currently the load balancer continues to select the > > failed servlet. I've tried using an http connector rather than ajp in the > > BalancerMember URLs but that made no difference. > > > > > This may sound quite rough and brutal, but it is after all an idea.. > > Since what you seem to want is that, when the servlet fails, that whole > > Tomcat would be taken out of the circuit (disabled in the Balancer), why > > don't you just shut down that Tomcat when you encounter this error ? > > > > For me, the question is whether Apache can detect the error and retry on another balancer member > (at least for GETs which are easy to replay). Some commercial LBs have this feature, which is useful > when you have an intermittent, somewhat infrequent error in an app which leads to the 500 being produced, > but which may not justify bringing down the Tomcat entirely. > > This simply avoids the bad user experience for the end user. > > Best, > Ryan > > > > Internal Virus Database is out-of-date. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.0.0/1490 - Release Date: 6/8/2008 5:32 PM > We recently deployed a service behind a balancer group (apache 2.2.8), mainly to enable us to have some hot backup servers with this kind of feature, to disable a backend server when it's corresponding DB cluster was unavailable, for instance. We configured our backends to return status 503 (Service Unavailable) when there was no DB available, but this did not do the trick - the error was passed through to the user. I had a brief look at mod_proxy_balancer.c to see if this kind of change would be easy to implement, and sadly it didn't look like it would be. The module finds the appropriate worker from its collection of child workers, according to the settings you set on the balancer pool, and then rewrites the internal URL for mod_proxy to then take over and do the actual proxying. When mod_proxy does the actual request to the backend server, it knows nothing about balancing or balancers, and then can't retry on a different balancer member, or even mark the failing balancer member as down (If I'm misreading this, please let me know!). Maybe we can hook in somewhere later in the request, and detect these sorts of transient, retriable failures, and then DTRT. Cheers Tom --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx