Thankfully (and shamefully) it did in fact turn out to be something on
our end. Basically there was object that had a reference to the response
output stream that would close the stream when it was getting garbage
collected which had as a side effect that tomcat would set the response
that owned th
So I set a conditional breakpoint for response.isCommitted() all the way
down in CoyoteAdapter.service() (called by Http11Processor.process())
and the response was committed at that point when this happened. Here is
the source where the breakpoint was:
// Parse and set Catalina and con
The source code for both is below (this code is actually from the spring
library if that makes any difference).
I really don't think the filters have anything to do with it. I just set
a conditional breakpoint in the first line of doFilter() in the first
filter that gets called by tomcat for when
So what does the first filter do? Does it do anything with the response
before chaining to the second one?
--David
Dan Adams wrote:
So every once in a while when you make a request to the server you won't
get anything back and the log will show that one of the filters
complained that response
So every once in a while when you make a request to the server you won't
get anything back and the log will show that one of the filters
complained that response is already committed. So I restarted tomcat
with the jpda debugger on, fired up my debugger in eclipse, and set a
breakpoint at the place
