tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
Date Fri, 14 Mar 2014 12:20:11 GMT
Hash: SHA256


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 
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:

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

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message