Summary: | Static Content Corruption | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Chris Donaldson <christopher.donaldson> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | arcanefang |
Priority: | P2 | ||
Version: | 5.5.20 | ||
Target Milestone: | --- | ||
Hardware: | Sun | ||
OS: | Solaris |
Description
Chris Donaldson
2008-08-08 12:11:27 UTC
(In reply to comment #0) > This problem is seen to happen in Tomcat 5.5.20 and 6.0.16 The line numbers quoted in the stack trace do not match either of the Tomcat versions above, nor could I find a Tomcat 5.5.x or 6.0.x version that they did match. I tried using the patch to identify an offset but that didn't work either. In short, it is very difficult to work out what exactly this stack trace represents. > In a highly threaded environment > ServletOutputStream's write method gets accessed by multiple threads, so > ServletOutputStream's write method may sometimes get called while the previous > thread's writing of the byte buffer is not yet finished or its own buffer is > not yet flushed, which results in corrupted output. Every response has its own ServletOutputStream. Since a response is handled by a single thread, I don't see how a threading issue can exist here unless response objects are being re-used across requests by the application. That would be an application bug. > The fix is to remove this optimization. The stack trace shows reading from a File. The optimisation the patch removes copies the data directly from the cache without any file reading. I can't see how the proposed fix relates to the stack trace. Further, removal of the optimisation makes it more likely that the content will be read from the file. Given that the stack trace is related to reading data from a file I would expect the proposed patch to make any error more likely not less likely. A Google search suggests that a lack of OS resources could also be a cause of this error. Given that the environment is highly threaded, and taking this to also mean highly loaded, this looks more like a JVM/OS issue to me. Therefore I am closing this as invalid as I can't see anything in the code that Tomcat is doing incorrectly. That said, I do have a nagging doubt I am missing the obvious so if I am, feel free to re-open and point it out. *** Bug 48760 has been marked as a duplicate of this bug. *** If you see this error then the users list is the best place to figure out what is going wrong. I'm quite happy to apply a patch to fix a problem I can't reproduce providing that: - there is a logical explanation for a) why the problem is occurring and b) how the patch addresses it - the patch is confirmed to fix the issue in an environment where the issue can be produced - the patch isn't going to cause a regression for other use cases If the discussion on the users list can provide satisfactory answers to all of the above points feel free to re-open this issue. |