tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
Date Fri, 14 Mar 2014 12:20:11 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message