> -----Ursprüngliche Nachricht----- > Von: Jim Jagielski > Gesendet: Mittwoch, 13. Februar 2008 19:00 > An: dev@httpd.apache.org > Betreff: Re: ping for http in mod_proxy > > > On Feb 13, 2008, at 12:41 PM, Plüm, Rüdiger, VF-Group wrote: > > > > Agreed, but I doubt that it is possible with a reasonable amout of > > health > > check frequency to find out before the first real request falls > > through, > > provided that your health checks are designed to only fail if the > > backend > > is down. If your health checks are smarter and notice that the > > backend will > > fail soon (e.g. because it reached 98% or 99% percent of its > > capacity) then > > this is a different story and can be very useful. > > Regarding the reactivation of a failed backend I fully > agree: Active > > health > > checks would be an asset here instead of just retrying failed > > backends periodically > > with real requests. > > > > Ideally, it would be nice if we had better insight on the > actual health of the backends than a simple "do they respond > to OPTIONS * and how long does it take", but that's pretty > much all we can do unless go full-on multicasting of info > ala mod_backhand... At least the balancer is setup to allow > for load balancing based on that, if the submodule/provider > actually existed :)
Right. Furthermore I guess we could create a generic module that needs a URL configured for a HEAD request that only replies 200 if the backend can still handle more requests. If it does not respond or with a different code this backend would be dead. I guess this module needs to fork a separate process / thread to do this checking periodically and modify the worker status accordingly. So much interesting work and so few time :-(. Regards Rüdiger
