-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Shanti,
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 < > ch...@christopherschultz.net> wrote: > >> >>> BTW, beware of known issue, mentioned in the FAQ, >>> http://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues >> >> +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 > <http://wiki.apache.org/tomcat/OutputStream>objects to save > resources, so it could be that when flush() is called from the > ImageIO, the particular > OutputStream<http://wiki.apache.org/tomcat/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 http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSMdhqAAoJEBzwKT+lPKRYB1gP/060YfcR6weyQCUyqhNXM3g5 DAISokCzJHoHTXlTyn3ekjwsr0w2NRpCdlqam/JLvDe9LEqOudyxT7vToJfsSe5p JIkI/p4aWAR5YizJ+blASpItN2/4jW4FTSBcfNTrvtKx7atUKbhvd9G6xOzmQsYA 6VPgFqJIwPW5bOf2KyHwrrKIPe8PhIva9eJKDJqRtWm0ruOmOxqUKn6ZTYkwcOrP L9DJSIcx0RPoX25IuqIA2lBOsHJzPsngUTiv/4wRUBun38XuBCvGdG+v6fW+jdvo Gg6TNlTxybNx6Wzs7Uk8/y/PVQGnZXr8ge1nN2/YoyUxEdegl7Ac25s7BeQZjdDI eey1xC9s9vJyz2YSn4TrTsD6iDfhZatU3JTt+5QdHFElkUgUhuI5g4Ivj4X4Nd+0 GyX20MN9y7k8DmGNSq6c7TB8jw1UwxFl9PUkGaXwQvtxHkMXe/xv+PAcINvo0nnw /VrWwKqzKg3QglzBuCvbNlV8SIJu2J/yusJXUq8THUvbkl9diimp+jQebjEi3SQD mtGgLd/+X8mzsEoM2w76ZMdQiw72gycGvebIF7793G2myHhvkYBab1Bjp6NpA/OA gFMWHOJFxrTB2ZgSTmXKCm2ScR28RkZAzF1rUzOqXYeApnyFPhrKAzfa9CzYQHsX U2YZMAhQnSK6udGCEPmC =Tfg4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
