tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Registering Plugins, e.g. javax.imageio...
Date Thu, 12 Sep 2013 15:06:18 GMT
Hash: SHA256


On 9/11/13 3:03 PM, Shanti Suresh wrote:
> Hi Konstantin, Hi Chris,
> On Wed, Sep 11, 2013 at 1:43 PM, Christopher Schultz < 
>> wrote:
>>> BTW, beware of known issue, mentioned in the FAQ, 
>> +1
> Could you please explain this bug better?  So from the nice writeup
> in the Wiki link above, I understand that the OutputStream object
> may be re-assigned by Tomcat to another servlet.  So what does this
> statement mean: "Tomcat recycles OutputStream 
> <>objects to save
> resources, so it could be that when flush() is called from the
> ImageIO, the particular 
> OutputStream<>object
> already belongs to another Response, which can produce the above 
> errors, when the Servlet tries to get a Session for example, or
> can generally lead to broken responses."

I had a little trouble with the term "recycle" a while back. In this
case the opposite of "recycle" is "discard". This means that the same
(underlying) OutputStream is used over and over again across lots of
requests. If you have ImageIO hold-on to a reference to one of these
things (that's the bug), it can corrupt a later response.

In other contexts, the term "recycle" actually means "discard", such
as in the system property org.apache.catalina.connector.RECYCLE_FACADES

> So my understanding of "flush()" is that any remaining bytes are
> written to the OutputStream.

Yes. But, if there are no additional bytes to send, it can still
interfere with the outgoing request (e.g. committing the response too
early, etc.).

> But nowhere is it mentioned that "flush()" closes the
> OutputStream.

It does not.

> So I am confused how a new Servlet cannot get a session object for
> a recycled OutputStream when all that's going on is that the
> remaining bytes are written out.  Is the "close()" method the
> culprit?

I think you are confused about a few things. Flushing the stream does
not close it, but the finalizer I believe also closes the stream as
well. Tomcat may not allow the stream to actually be closed (because
Tomcat wants the stream to say open... at least the "stream" object
that it presents to servlets), so the close() does nothing. The
flush(), however, still occurs.

Flushing the OutputStream of a response "commits" the response --
meaning that the bytes are actually sent to the client. If that
happens (remember: ImageIO is interfering with a "later" and unrelated
request to the image-related one) than the later request -- still
in-process -- might not have expected that response-commit and things
like request.getSession() can fail because those calls must be made
before the response has been sent to the client (because creating the
JSESSIONID cookie requires setting a response header).

Hope that helps,
- -chris
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message