Hi Tim,
Tim Redding schrieb:
Hi,
We are experiencing intermittent problems with a particular site that is not
returning the correct file that is requested. For instance if we request
the index.html file we actually get a css file or even an image. From the
apache access log you can see that the size of the index.html file grows on
the second request. This is because a gif was actually returned.
XXX.XXX.XXX.130 - - [10/Jul/2008:15:10:39 +0100] "GET /index.html HTTP/1.1"
200 1068
XXX.XXX.XXX.130 - - [10/Jul/2008:15:13:10 +0100] "GET /index.html HTTP/1.1"
200 9526
XXX.XXX.XXX.130 - - [10/Jul/2008:15:13:48 +0100] "GET /index.html HTTP/1.1"
200 1086
This is pretty serious (I assume that 1086!=1968 was a typo).
No error messages are logged in the mode_jk.log file.
We have Apache/2.2.3 on the front on a Tomcat 6.0.16 server with mod_jk
(version unknown but fairly recent). We have all assets in our war file.
When we hit Tomcat directly on port 8080 it serves the correct file. And to
fix the problem an apache restart seems to sort things out.
On this server with have 2 vhosts. One is a simple nothing fancy static
site and the other forwards everything to our Tomcat server. Below I've
included our mod_jk config and a snippet of our httpd.conf.
Any ideas or things to try would be most appreciated.
What's you platform and which httpd MPM (prefork orworker or something
else) do you use? For some platforms (e.g. AIX) the detection of
multi-threading in httpd during mpod_jk build-time was broken. Starting
with 1.2.24 we build always including multi-thread support unless
explicitely stated via a configure option. If you 1.2.23 build is not
thread safe, but your httpd uses threads (like with worker mpm), then
such trouble is possible, although more likely you would see crashes
etc. For most platforms like Linux and Solaris the threading detection
was OK already before 1.2.24.
Another possible (but not very likely) cause could be bug 44494 of
Tomcat 6.0.16 which under certain circumstances could leave data in the
request object after request handling completed. You could try either
downgrding to 6.0.15 or upgrading to the soon to be expected 6.0.17.
I would also add the access log on the Tomcat side. If you find the same
phenomenon there, then it's unlikely, that httpd/mod_jk are responsible
and the reason should be inside Tomcat or the webapp.
Can you reproduce the problem on a test system?
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
