Pid wrote:
Andreas Deller wrote:Pid wrote:Andreas Deller wrote:HiI have activated LiveHttpHeaders and the RequestDumperValve and fortunately ran into the problem in my development environment. Sorry for the long posting, but it seems necessary to me. Important notes: - Between the client and the server, there is a reverse proxy.RDV is reporting that the file is has content length and type null.It's likely that the content type seen, 'text/html' is just a being set as a default.Looks like Tomcat is having trouble getting the file off the disk. Which version of Tomcat (you mentioned two) did this occur under?5.0.28 on Linux (Debian) and Solaris 9. It also occurred with 4.1.30.Are you using APR/tcnative?No, I haven't installed any of them.APR offers a worthwhile performance improvement for OS native operations like serving static files. It also might offer an route around any Java issues, if you're able to use the OS 'sendfile' function.
Thanks for the optimization hint, although we don't encounter performance problems so far.
(Actually not sure if this is works for TC5.0, anyone list?)I think that the problem is more rare using JDK 1.5.0_09 than 1.4.2_06, but of course I couldn't measure this.If the problem occurs with both JVMs and both versions of Tomcat, you may have encountered a rare but unknown error condition, or it's not Java/Tomcat...In the former case, I'd try to eliminate the room for error between versions by standardising JVM/Tomcat versions.
That surely sounds like a good idea. I wasn't aware that there are such recommendations. Can you give me a pointer where to find these JDK/Tomcat pairs standards? I found none in http://tomcat.apache.org/whichversion.html http://tomcat.apache.org/faq/version.html
In the latter case, it could be an OS issue. The RD Valve reported no file size, or file data (from which it could determine MIME info), suggesting that Tomcat was unable to read the file data off the disk for some reason.
That's possible, but I think it unlikely, because the error occurs both on Debian Linux and Solaris.
Try checking the disk for capacity, damage issues.
I think I can rule this out as it happens in three totally different environments.
If it's always the same directory, I'd create a fresh copy of the directory by uploading all of the files to a new dir, and symlinking/altering the old path to the new one.
Since the application already runs in different environments (and gets rebuilt after every clean), this has already been done.
The image files aren't being served off a network file share or something are they?
Yes, they are served from a NAS, at least in two environments. Could this be a problem?
smime.p7s
Description: S/MIME Cryptographic Signature
