tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Adams <...@ifactory.com>
Subject Resolved: Response committed before getting to the filters
Date Fri, 06 Oct 2006 20:06:08 GMT
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 the stream as being committed already. Thanks for the help.

Lesson learned: double check that streams are closed correctly.

On Fri, 2006-10-06 at 12:33 -0400, Dan Adams wrote:
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message