RE: change BalancerMember status if servlet fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux