Mark,
so conceptually, what are the differences between
AsyncContext.dispatch(...)
FilterChain.doFilter(...)
RequestDispatcher.forward(...)
If we allow asynchronous threads to call doFilter, then why do we have
RequestDispatchers?
If we allows asynchronous thread to call doFilter, then should they also be
able to call RequestDispatcher.forward? If so, then why do we need
AsyncContext.dispatch?
cheers
On 7 December 2014 at 12:39, Mark Thomas <markt_at_apache.org> wrote:
> On 06/12/2014 22:40, Greg Wilkins wrote:
> > Mark,
> >
> > the problem with allowing a filter chain and servlet to be invoked from
> > another thread like that (even if run through
> > AsyncContext.start(Runnable)) is that any exceptions thrown will not be
> > correctly handled an error page dispatch.
>
> Apps are responsible for handling all errors on async threads [1].
>
> In Tomcat, if the app calls complete() and the response has an error
> status code we use the standard error page mechanism to generate the
> response. If the app calls dispatch(), we assume that the dispatch is to
> an error page.
>
> > There is also the scope of the FilterChain to be considered. Can it be
> > reused like RequestDispatchers between different threads?
>
> That is a container concern. Tomcat does re-use them and allowing the
> filter chain to be used like this does change when it can be recycled. I
> haven't looked into this in detail but I think this is manageable.
>
> > I think there are probably other complications that we have not yet
> > thought about, so I'm leaning towards this being illegal.
>
> Possibly, but I think we have already identified the main ones. I think
> it is worth exploring whether this can be allowed.
>
> > Note that same issue has currently been raised against Jetty, and while
> > I've not had time to fully understand the use-case yet, it does look
> > like a valid use case... but perhaps it needs a different way of
> > integrating with a container rather than interrupting the filterchain.
>
> If the EG indicates that it is prepared to drop the restriction in 6.2.3
> for async requests if it is demonstrated that it is possible for the
> filter chain to be invoked from an async thread then I'd be happy to
> experiment with allowing this in Tomcat for a few releases to see if any
> regressions emerge.
>
> Mark
>
> [1] Servlet 3.1, Section 10.9.2, para 11 (page 10-110)
>
>
> > On 6 December 2014 at 01:14, Mark Thomas <markt_at_apache.org
> > <mailto:markt_at_apache.org>> wrote:
> >
> > Hi,
> >
> > Section 6.2.3 includes the following text:
> > <quote>
> > A Filter and the target servlet or resource at the end of the filter
> > chain must execute in the same invocation thread.
> > </quote>
> >
> > As a result of a bug raised against Apache Tomcat [1] I am seeking
> > clarification of the meaning of that sentence.
> >
> > As written, the meaning seems unambiguous. However, does it apply
> when
> > the request is in asynchronous mode? To put it another way is the
> > following legal?
> > - filter calls ServletRequest.startAsync()
> > - filter calls AsyncContext.start(Runnable)
> > - That Runnable called FilterChain.doFilter()
> >
> > If the above were legal it creates some implementation issues for the
> > containers but they are not insurmountable. Clearly there is a user
> > requirement to do this else the bug would not have been raised.
> >
> > Looking back at the original discussion that led to this text being
> > added, async behaviour was not considered.
> >
> > So is the above legal, in which case we need to clarify 6.2.3 or is
> it
> > illegal? I'm currently leaning towards it being legal.
> >
> > Mark
> >
> >
> > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=57284
> >
> >
> >
> >
> > --
> > Greg Wilkins <gregw_at_intalio.com <mailto:gregw_at_intalio.com>> @ Webtide
> > - /an Intalio subsidiary/
> > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> > http://www.webtide.com advice and support for jetty and cometd.
>
>
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.