-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Clemens,
On 3/14/14, 3:33 AM, Clemens Wyss DEV wrote: >> If you are starting a new thread to generate a PDF > yes we do >> but blocking the request-processing thread waiting for it to >> complete > no we don't > >> Okay, so this is your error handler checking the value of >> request.getRemoteAddr() and throwing an error because the IP >> address is not valid for that URL, right? > true > >> and the container (Tomcat) assumes that the web application is >> not playing games with the request, response, etc. > at most getting "stuff" from the request (which we expect(ed) to > be "immutable") Okay, you need to fix this. In the meantime, at least set RECYCLE_FACADES which should help quite a bit. Instead of getting bogus data after control has returned to the container (which expects to have complete control -- you have removed control from the container by launching your own thread and retaining references to the request and response), you should end up getting lots of errors. Until you can change your application to use asynchronous IO, you probably want to change things so that the request-processing thread performs your long-running requests instead of delegating them. That should fix the majority of the problems you are experiencing. As for the wisdom of switching to async IO, it depends upon your situation. If most of the wait-time has to do with gathering data -- say, from a database or other relatively slow source -- then async makes sense since the request-processing thread can be used to handle other requests in the meantime. If, however, most of the time is taken actually generating the PDF (just a huge amount of content), then switching to async won't actually buy you anything: you would be better off just using the container's request-processing thread to handle things for you. >> that can corrupt your requests (and responses) at best and be a >> severe security vulnerability at worst > > AGAIN we were not aware of It's okay. You just have to be aware that this is almost certainly the root cause of the problems you are observing. >> Tomcat re-uses Request and Response objects to reduce the amount >> of heap-thrashing that would otherwise occur > >> which is officially broken if it relies on request or response >> objects outliving the time during which the request-processing >> thread has been allocated to a particular request > > Reading the spec > http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html > > > only athenticate and getSession are explicitly meant to not be called > after a response has been commited. Also nearly everything in the HttpServletResponse class. > Where do I find the sepcification you mention? I think you misinterpret the meaning of "committed". In the spec, the response is "committed" when the first byte of the response has been sent back to the client. The request is still in-progress even after it has been "committed", and the servlet may continue to run. The specs themselves can be found from the references here: http://wiki.apache.org/tomcat/Specifications Read section 3.11 of the 3.0 version of the spec. (The same section exists in other versions... it just might have a different section-number). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIvP4AAoJEBzwKT+lPKRYzSQQAKUswaLJ0Ej/fGKkSgFyrcAE R6YrWtWhkomKtWZy7np6ZU33a2PD6oDQA8XqT9FmsENN+Wts3ES1fWMrSjtPHliA pHMv46cbOZhwzB17XdnXT0FikSpWISfQrdtrjnApbR1Q+49rkrZImpCAesn3oXWK PPozaCiPr6pSyg+I0iFZSwRFdX6CDzbRvZcfxxDin6B76T/VsuuY4HbRT6gO0u3R FhckP05onAqsyisfHpxKXtPY9RdsTPytePuOo34GFYkudMbxIZFapjLk4rzoL7G1 nH2GKdCDd7SKVR9zrox3AnCJpFfJxhqceDiipCOQq94j2tXXtQoy3rqwc5HLYA6Z UsKzewaJaiiirJ/UgVPtzudd8jH/eouV1uaIsR+vCoShnfKNRzDPvxNiRDmUs6ub EbqcBF+nBKMkHE8jJGv0TMHp9sqQzm16h07gl/xWii5ug3J/PzeYt2JwdMPIO3DW 9CSzOViA8QvWQCW5qUtQBD3VhbW7vcpX9MfKK3TdojteQo/wa2GGqLxUkK7+ZGxh FIAW8G8cGqKthp5yayGH203uRxyNHYn7Z5gzUjVm/99Jrs60lKRgjbU42/YpZhzv 3OHooWTvrAd87PLIcflJSc9KXAw9ckvzQ90jPfQy+1mx1aUZ8csmtfOHyXBpIj3d 1J1XRMMsIC10I8LDkdHf =U7aZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
