I have a Tomcat Filter that delegates requests to the a handling object depending on the URL. This is the only filter in the FilterChain. I have an Ajax app that hammers this filter with lots of requests.

Recently I noticed an issue where the filter's doFilter method is often called with a committed response as a parameter (Internally, it is the coyote response that is marked committed).

It seems to me that the only way that this can happen is if the recycle() method is not called on this coyote response. I have checked to make sure that I am not keeping references to any of the request, response, outputStream, or writer objects. Additionally, I made sure to close the outputStream in a finally block. However, this doesn't resolve this issue.

This sounds like I am doing something to abuse the servlet container but I am having trouble tracking it down.


What version of Tomcat are you using? To me this sounds like a bug in Tomcat, I can't think of any reason why your doFilter method should be called with a response that's already been committed (if that filter is the only one in the chain, are you sure about this?).

+3  A: 

I have tried using Tomcat 6.16 and 6.18. This is definitely is the only filter in the chain.

It seems that something is keeping a reference to the servlet outputStream. I wrapped the ServletOutputStream in my own OutputStream and then made sure the reference is destroyed. This fixed the issue so that I no longer see a committed response passed in.

This is an odd side effect of holding a reference. But I don't think it qualifies as a Tomcat bug. More likely a bug in ImageIO.createImageOutputStream() that I suspect is holding the reference.

Casey Watson
we had to do the exact same thing. Wrap the output stream and prevent it from committing the response until we were ready.