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 instances.
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: 10.35.32.123 - - [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:10.35.32.123 - - [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; Path=/"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
http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass 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=OnThe 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.
Regards, Rainer --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|