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.
ajp.patch
Description: Binary data
balancer.patch
Description: Binary data
