>>>>> 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.
[...]
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
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 56 days til DevNexus 2015
| 66 days til JavaLand 2015
| 76 days til CONFESS 2015