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 response.isCommitted()
evaluates to true. As soon as it happened again that breakpoint got hit
and response.isCommitted() was, in fact, true. But in every other normal
request the breakpoint never gets hit.
This is what the first filter does (sorry looks ugly in email):
public final void doFilter(ServletRequest request, ServletResponse
response, FilterChain filterChain)
throws ServletException, IOException {
if (!(request instanceof HttpServletRequest) || !(response
instanceof HttpServletResponse)) {
throw new ServletException("OncePerRequestFilter just supports
HTTP requests");
}
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String alreadyFilteredAttributeName =
getAlreadyFilteredAttributeName();
if (request.getAttribute(alreadyFilteredAttributeName) != null ||
shouldNotFilter(httpRequest)) {
// proceed without invoking this filter
filterChain.doFilter(request, response);
}
else {
// invoke this filter
request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE);
doFilterInternal(httpRequest, httpResponse, filterChain);
}
}
and doFilterInternal() is:
protected void doFilterInternal(
HttpServletRequest request, HttpServletResponse response,
FilterChain filterChain)
throws ServletException, IOException {
SessionFactory sessionFactory = lookupSessionFactory(request);
Session session = null;
boolean participate = false;
if (isSingleSession()) {
// single session mode
if (TransactionSynchronizationManager.hasResource(sessionFactory))
{
// Do not modify the Session: just set the participate flag.
participate = true;
}
else {
logger.debug("Opening single Hibernate Session in
OpenSessionInViewFilter");
session = getSession(sessionFactory);
TransactionSynchronizationManager.bindResource(sessionFactory,
new SessionHolder(session));
}
}
else {
// deferred close mode
if (SessionFactoryUtils.isDeferredCloseActive(sessionFactory)) {
// Do not modify deferred close: just set the participate flag.
participate = true;
}
else {
SessionFactoryUtils.initDeferredClose(sessionFactory);
}
}
try {
filterChain.doFilter(request, response);
}
finally {
if (!participate) {
if (isSingleSession()) {
// single session mode
TransactionSynchronizationManager.unbindResource(sessionFactory);
logger.debug("Closing single Hibernate Session in
OpenSessionInViewFilter");
try {
closeSession(session, sessionFactory);
}
catch (RuntimeException ex) {
logger.error("Unexpected exception on closing Hibernate
Session", ex);
}
}
else {
// deferred close mode
SessionFactoryUtils.processDeferredClose(sessionFactory);
}
}
}
}
On Fri, 2006-10-06 at 11:00 -0400, David Smith wrote:
> 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 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.
> >
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
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]
