tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 45601] Static Content Corruption
Date Sat, 09 Aug 2008 16:29:04 GMT

Mark Thomas <> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Mark Thomas <>  2008-08-09 09:29:02 PST ---
(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.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message