On 07/12/2014 13:56, Greg Wilkins wrote:
> Mark,
>
> so conceptually, what are the differences between
>
> AsyncContext.dispatch(...)
Only available in async.
Switches from async to sync mode.
> FilterChain.doFilter(...)
Available in async or sync.
Remains in the current mode (sync or async) and continues from the
current point in the filter chain.
> RequestDispatcher.forward(...)
Available in async or sync.
Remains in the current mode (sync or async) and starts at the top of the
filter chain for the specified request.
> If we allow asynchronous threads to call doFilter, then why do we have
> RequestDispatchers?
To differentiate between starting at the top of the filter chain and
continuing from the current position in the filter chain.
> If we allows asynchronous thread to call doFilter, then should they also
> be able to call RequestDispatcher.forward?
Yes.
> If so, then why do we need AsyncContext.dispatch?
To differentiate between a dispatch that remains in async mode and one
that switches from async to sync.
To some extent I am playing devil's advocate here. The original bug
report has highlighted a lack of clarity within the servlet spec about
when it is legal to switch to async and when it isn't. It is my position
that this must be addressed in the next revision of the servlet spec.
I do not have strong views on exactly how it is clarified but my
starting position is that we should not limit when it is legal to switch
to async without a good reason.
Mark
>
> cheers
>
> On 7 December 2014 at 12:39, Mark Thomas <markt_at_apache.org
> <mailto: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>
> > <mailto: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>
> <mailto: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 <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.