Ruediger Pluem wrote:
On 07/27/2006 11:31 AM, Jean-frederic Clere wrote:
Ruediger Pluem wrote:
On 07/26/2006 10:53 PM, Jean-frederic Clere wrote:
I already have a prototype of an external health checker process that
uses an AJP cping/cpong and a simple connect for http/https.
Basicaly mod_proxy uses the health_worker_method routine to write and
read from a slot mem that contains the information of the workers + a
health information. A balancer could check the health information before
using the worker. The health checker process uses the worker description
(thru the health_worker_method) to check if the back-end service is
running.
Sorry, you may have explained that before, but why using an external
health
checker process?
The idea is to have the health check independant from the requests so
that httpd knows in advance that a worker is not working.
Ah, now I get it. Ok, I guess we both have slightly different ideas about what
to health check. Your idea is more of a server health check and is somewhat
similar to what HW loadbalancers are doing: Check each backend on a regular
schedule if it is still available.
Yep.
My idea is more of a connection health check. I want to check if the connection
I leased from the pool is still healthy.
You want to check all the connections of the pool corresponding to the
worker but not all the workers.
If it is not that does not mean
necessarily that the server in the backend failed.
That probably means the socket has been closed ;-)
It could be just this connection. So the default response on a faulty connection
would be to close this one and try with a new one.
With TC that means you create a new thread in TC, we must not overload
the back-end server.
Only if this fails also then
there seems to be something wrong with the backend server. This is more like
what
most DB connection pools offer with a health-check query.
I think both ideas make sense. Of course the connection health checks should be
simpler than the server health check to avoid too much overhead and too much
lost time.
That is the reason why I think that e.g. doing a HTTP request on a HTTP
connection
leased from the pool is unreasonable.
Yes... That is hard to check if http/https back-end server is healthy or
not.
We need some quick network layer check in this
case, whereas in the AJP case CPING/CPONG has still an acceptable overhead.
Finally I think if we have a good provider interface we can use the health
check providers
for both kind of health checks.
Right an internal httpd provide would have the 2 health checks ways and
external one probably one.
If the health check is external we only need to process the result, if
it is internal both health check and result processing are needed.
We only need to create the frameworks for them
to start in different parts of the code (separate process in your case, in my
case
I would guess that it needs to replace is_socket_connected which is called from
ap_proxy_connect_backend)
Regards
Rüdiger
