jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: Clarification of threading requirements of section 6.2.3

From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
Date: Mon, 08 Dec 2014 13:35:37 -0800

On 12/8/14, 12:17 PM, Edward Burns wrote:
>>>>>> On Sat, 06 Dec 2014 00:14:51 +0000, Mark Thomas <markt_at_apache.org> said:
> MT> Hi,
> MT> Section 6.2.3 includes the following text:
>
> Spec> A Filter and the target servlet or resource at the end of the
> Spec> filter chain must execute in the same invocation thread.
>
> MT> As a result of a bug raised against Apache Tomcat [1] I am seeking
> MT> clarification of the meaning of that sentence.
>
>>>>>> On Sat, 6 Dec 2014 23:40:15 +0100, Greg Wilkins <gregw_at_intalio.com> said:
> GW> the problem with allowing a filter chain and servlet to be invoked from
> GW> another thread like that (even if run through AsyncContext.start(Runnable))
> GW> is that any exceptions thrown will not be correctly handled an error page
> GW> dispatch.
>
> MT> Apps are responsible for handling all errors on async threads [1].
>
> MT> [1] Servlet 3.1, Section 10.9.2, para 11 (page 10-110)
>
> Spec> If the application is using asynchronous operations as described
> Spec> in Section 2.3.3.3, "Asynchronous processing" on page 2-10, it is
> Spec> the applications responsibility to handle all errors in
> Spec> application created threads.
>
> GW> There is also the scope of the FilterChain to be considered. Can it be
> GW> reused like RequestDispatchers between different threads?
>
> MT> That is a container concern. Tomcat does re-use them and allowing the
> MT> filter chain to be used like this does change when it can be recycled. I
> MT> haven't looked into this in detail but I think this is manageable.
>
> MT> As written, the meaning seems unambiguous. However, does it apply when
> MT> the request is in asynchronous mode? To put it another way is the
> MT> following legal?
> MT> - filter calls ServletRequest.startAsync()
> MT> - filter calls AsyncContext.start(Runnable)
> MT> - That Runnable called FilterChain.doFilter()
>
> We expose the FilterChain to the filter as a way to give Filters a high
> degree of control of what happens:
>
> Spec> Filters use the FilterChain to invoke the next filter in the
> Spec> chain, or if the calling filter is the last filter in the chain,
> Spec> to invoke the resource at the end of the chain.
>
> If the Filter wants to go async, allowing them to do so would be
> consistent with that design intent. In the absence of further data, let
> me suggest some alternate text for section 6.2.3.
>
> Proposed623> When operating in synchronous mode, a Filter and the target
> Proposed623> servlet or resource at the end of the filter chain must
> Proposed623> execute in the same invocation thread. When operating in
> Proposed623> asynchronous mode, a Filter and the target servlet or
> Proposed623> resource at the end of the filter chain must execute on the
> Proposed623> invocation thread to which control is handed when the
> Proposed623> asynchronous processing commences.
>
> How does this sound? I'm open to changing this text of course.
This sounds good to me.
Shing Wai Chan
>
> [...]
>
> MT> If the EG indicates that it is prepared to drop the restriction in 6.2.3
> MT> for async requests if it is demonstrated that it is possible for the
> MT> filter chain to be invoked from an async thread then I'd be happy to
> MT> experiment with allowing this in Tomcat for a few releases to see if any
> MT> regressions emerge.
>
> I appreciate the offer.
>
> Ed
>
> MT> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=57284
>