httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathias Herberts" <mathias.herbe...@gmail.com>
Subject Re: mod_proxy and balancer problems
Date Thu, 05 Oct 2006 09:07:58 GMT
As I mentioned a few days ago here are my patches for mod_proxy.

They modify mod_proxy behaviour in several ways to better fit our
production environment where we heavily use Apache and Tomcat.

Just so you understand our context, we use a pool of Apache servers as
front-ends to Tomcat application servers. Each Apache server serves
several virtual hosts which connect (using AJP 1.3) to backend Tomcat
servers.

The version of Apache we use is 2.2 and the version of Tomcat 5.5.

The first patch (ajp.patch) modifies the behaviour of mod_proxy,
introducing two config parameters.

The first new parameter is 'forceclose' which can have values 'On' or
'Off'. The default config for a worker is 'Off'. If this parameter is
set to 'On', connections to the backend will not be reused. This means
the behaviour will be similar to that of AJP 1.2 in mod_jk, once a
worker is chosen, the connection is established and the request sent.
Once the response is received, the connection to the worker is closed.

This behaviour is needed when you have a frontend Apache managing
requests to several Tomcat servers and working in MPM prefork. Imagine
you have 2 Tomcats with a capacity of 10 threads each. A frontend
Apache server serves request for both Tomcat. When a first burst of 10
parallel request to the first Tomcat arrives, Apache will use 10
processes which each will connect to the Tomcat server. Without the
'forceclose' patch, those 10 connections will remained open.
Now imagine a second burst of 10 requests arrives, this time to the
second Tomcat. The prefork model in use will have the 10 existing
processes affected to those ten requests, if an 11th request arrives
for Tomcat1, a new process will be forked by Apache, but there are
already 10 connections to Tomcat1 and those 10 connections are tied to
the 10 processes processing requests for Tomcat2, meaning we will be
unable to handle the 11th connection to Tomcat1 even though there are
currently no request being processed by Tomcat1.

The 'forceclose' patch allows the connections to be closed and thus
will avoid this situation.

The second parameter added is 'connecttimeout' which takes a value in
milliseconds. This defines a connection timeout for a worker,
mod_proxy will not wait more than this number of milliseconds when
connecting to the backend Tomcat server.

This patch is needed as in Tomcat 5.5, when the maximum number of
threads is reached the AJP connector does not refuse the connection
but waits until a thread becomes ready. Having a connection timeout
allows to control how long we will wait for a connection with a finer
grain than using the value of the 'timeout' parameter which defines
how long to wait for read/write ops on the backend connection.

As a matter of fact for this patch to function properly Tomcat (5.5.17
at least) should be patched to allow the setting of a TCP backlog on
the AJP connectot. The default code in Tomcat uses 0 as the backlog
thus using the default OS value for the tcp backlog (which can be
quite high).




The second patch (balancer.patch) modifies the behaviour of the
balancer to overcome some of the caveats I mentioned earlier.

The first modification is the way session bound requests are handled.
With my patch the 'redirect' parameter is ignored for session bound
requests and failed workers are retried (which was not the case
previously).

The second modification is the ability to have a value of 0 for
'loadfactor' thus allowing to have workers which will only handle
session bound requests. This also allows to configure a behaviour
similar to the one that was possible with local workers and
'local_worker_only' in earlier versions of mod_jk.

Those patches have been reviewed and tested so they should be considered safe.

I am of course available to provide any supplemental information needed.

Regards,

Mathias.

Mime
View raw message