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 configuration specific
// request parameters
if ( postParseRequest(req, request, res, response) ) {
// Calling the container
// BREAKPOINT IS HERE
connector.getContainer().getPipeline().getFirst().invoke(request,
response);
}
I'm going to try to go ever further down and see if there is a point at
which it isn't committed.
On Fri, 2006-10-06 at 10:51 -0400, 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 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 in the filter where this message is printed.
>
> My app has 2 filters right now and the breakpoint is in the second
> filter. So when I hit the breakpoint I went down in the stack trace to
> the point at which tomcat calls doFilter on the first filter in the
> filter chain. At that point is the stack, response.isCommitted()
> evaluates to 'true'(!?). Exploring the objects the response shows that
> the headers written so far are:
>
> Transfer-Encoding = chunked
> Date = Fri, 06 Oct 2006 14:33:33 GMT
>
> and contentLength == -1.
>
> Why would the response be committed before even getting to any of the
> code in my application? Even suggestions on what to investigate further
> would be help at this point. Thanks in advance.
>
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
