tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Intermittently a Tomcat’s 7's response loses all (non-Coyote-added) headers
Date Thu, 03 May 2018 20:21:02 GMT
On 03/05/18 15:47, R Mundell wrote:


> I don’t believe it’s actually possible for the filters or the servlet to remove headers
even if they want to (they don’t appear to have any access to the MimeHeaders of the Coyote
“Response” object, and the HttpServletResponse object doesn’t have any methods which
allow header removal).


> The only clue we have is occasionally we see “INFO: Encountered a non-recycled response
and recycled it forcedly.” in the logs, but these errors are infrequent compared to the
number of instances of the problem, and the timestamps of these errors don’t correspond
to when users have reported the error.

That generally indicates two threads accessing the same request object.

> My best guess would be somehow the Coyote “Request” object is accidentally accessed
by two threads concurrently to service two requests, and one request is calling the Request.recycle()
(which is calling headers.recycle() which removes all of the headers) but I’m struggling
to see how that could happen. Note we are not using async servlets.

I think you are on the right track. Possible causes:
- Tomcat bug
- application code (or library code) retaining references to
  - request object
  - response object
  - InputStream
  - OutputStream
  - Writer

> I appreciate 7.0.72 isn’t the very latest and greatest version but I can’t find anything
in the change log for later 7.x, 8.x, 8.5.x or 9.x releases which indicate this is a known
issue or resolved.

There is an element of needing to know what to look for in the change
log. Usually because this sort of error can result in response mix-up
which is a security issue.

Some possible candidates:
- BZ 60409 fixed in 7.0.74
- Sendfile & pipelining in 7.0.77

> Any ideas about how to further diagnose this would be very gratefully received. Otherwise
our next step is to blindly update to later versions and just hope it goes away.

Without a way to reproduce this more frequently, tracking this down is
going to be tricky. I'd suggest at least testing with the latest 7.0.x
release - better still the 7.0.87 RC currently being voted on over on
the dev@ list - and seeing what results you get.

The other thing to try is setting:



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

View raw message