On 08/12/2014 20:17, 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.
I'm wondering what the motivate for adding the "same thread" requirement
was in the first place. That was never explained.
Requiring async requests to remain on a single thread seems to be
defeating the whole point of asynchronous processing. I think that this
requirement should be removed for async processing.
Absent a justification, I think the requirement should be removed from
sync processing as well.
> 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.
I'll add this to my TODO list.
Mark