Reply to comment

RE: "proxy_balancer" | stickysession

By King Holger (CI... at 10/15/2010 - 05:32

Hello Rainer,

it's a pity - but the clocks are in sync (using NTP). On both Tomcats and the Apache2 instances.

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".

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

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

Any more hints to identify the problem? The problematik POST request seems to be:
This POST throws a 500 status code.

Hi Holger,

On 14.10.2010 16:16, King Holger (CI/AFP2) wrote:
I assume the clocks on the Apache and Tomcat servers are in sync? In the
Apache access log the timestamp is "11:45:03". Apache uses as timestamp
the time when the request arrived. Tomcat logs using the time when the
request finished. In the access log snippet for the Tomcat access log
you provided, we can see no POST for this session id at or after
"11:45:03". The only entry that fits the URL is already two seconds
before. I hope the clocks are right ...

So either the request is logged further down, which would indicate that
it took quite long, or it didn't actually reach Tomcat, or it is still
stuck in it. I would hope and expect, that your Apache error log does
contain an indication for the failure. Remember that it could be logged
in the error log later than "11:45:03", because the timestamp in the
error log will be when the actual error happened, the timestamp in the
Apache access log when the request came in.

Anything in the error log? Any corresponding POST with the right session
id further down in the Tomcat access log?

If we suspect, that some kind of timeout is happening, then we would
want to add "%D" to the access log formats in Apache and Tomcat. %D logs
the duration of the request, for Apache in microseconds, for Tomcat in