httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: [users@httpd] "proxy_balancer" | stickysession
Date Fri, 15 Oct 2010 13:26:20 GMT
On 15.10.2010 12:32, King Holger (CI/AFP2) wrote:
> it's a pity - but the clocks are in sync (using NTP). On both Tomcats and the Apache2

Good to know.

> According to the following command output:
> grep -i "52C326B80A73EFF19CEE49B013533F06" localhost_access_log.2010-10-14.log
> the last pattern match for the JSessionID mentioned below is:
> - - [14/Oct/2010:11:45:01 +0200] POST /servlet/ClientIO/90i8dcztq97l/s6/21i
HTTP/1.1 200 197 52C326B80A73EFF19CEE49B013533F06.rb-wcmstc2
> So, I cannot find any further request logged further down in Tomcat "rb-wcmstc2".

So we deduce, that either the request is still hanging inside Tomcat or 
it never reached Tomcat. Although the latter is more likely, you can 
check: if you have the Tomcat manager webapp deployed, you can look at 
the status page, which shows a list of all in-flight requests.

> Due to an already overwritten error.log (log-rotation), I do not have any more access
to the Apache2 error-log. :(

Then there's likely no way forward for this incident. We would nee dto 
wait for the next one :(

> We will add the "%D" to the log format string on both Apache2 and Tomcat.

Good, it's helpful in a lot of situations anyhows.

> Any more hints to identify the problem? The problematik POST request seems to be:
>> - - [14/Oct/2010:11:45:03 +0200] "POST /servlet/ClientIO/90i8dcztq97l/s6/21j
HTTP/1.1" 500 1258
>> "-" "Jakarta Commons-HttpClient/3.1" "JSESSIONID=52C326B80A73EFF19CEE49B013533F06.rb-wcmstc2"
>> "52C326B80A73EFF19CEE49B013533F06.rb-wcmstc2" "JSESSIONID=B3C4AABB5F983A0E9D6478C42C88A5C4.rb-wcmstc1;
> This POST throws a 500 status code.

Sorry, to many possible reasons in the proxy for that. You need the 
error log.

You can try to make your setup a bit more robust by looking at the 
parameter table given at

For the ajp workers, the following parameters come to mind:

- ping (e.g. ping=10s)
- connectiontimeout (e.g. connectiontimeout=10s)
- timeout (e.g. timeout=120s)
- keepalive=On

The 10 second timeouts could also be lowered to e.g. 5 or 2 seconds if 
you are reasonably sure that you don't have any longer GC pauses on the 
Java back-ends. A good value for the general timeout depends on your 
expectation of response times the back-end will be able to support as 
long as it is running well. The "%D" in the access log will help you get 
some real numbers.



The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message