I will use PROVISIONALLY CLOSED to mean, "I think the resolution
represents the consensus but if it needs to be reopened, it can."
>>>>> On Mon, 8 Dec 2014 12:17:02 -0800, Edward Burns <edward.burns_at_oracle.com> said:
EB> If the Filter wants to go async, allowing them to do so would be
EB> consistent with that design intent. In the absence of further data, let
EB> 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.
EB> How does this sound? I'm open to changing this text of course.
>>>>> On Mon, 08 Dec 2014 13:35:37 -0800, Shing Wai Chan <shing.wai.chan_at_oracle.com> said:
SWC> This sounds good to me.
MT> I'm wondering what the motivate for adding the "same thread" requirement
MT> was in the first place. That was never explained.
MT> Requiring async requests to remain on a single thread seems to be
MT> defeating the whole point of asynchronous processing. I think that this
MT> requirement should be removed for async processing.
MT> Absent a justification, I think the requirement should be removed from
MT> sync processing as well.
>>>>> On Tue, 09 Dec 2014 10:13:59 +1100, Stuart Douglas <stuart.w.douglas_at_gmail.com> said:
SD> I guess my main concern here is that there is not really any way to hand
SD> off to another thread so that only one thread can be using the
SD> request/response at a time.
SD> Basically I am talking about some kind of AsyncContext.delayStart()
SD> construct that will not dispatch the task until the current call stack
SD> has returned to the container (or just change the semantics of start()
SD> to match). This will make sure that only one thread is using the request
SD> and response, without needing to resort to synchronization or other
SD> thread safety constructs.
>>>>> On Mon, 08 Dec 2014 23:56:44 +0000, Mark Thomas <markt_at_apache.org> said:
MT> I don't see the issue here. Once startAsync() has been called the
MT> container has no need to access the request or the response (until
MT> dispatch() or complete() is called so thread-safe access to these
MT> objects is simply an application concern.
I will change the "asynchronous mode" sentance to read:
When operating in asynchronous mode no such requirement exists. The
caller that caused entry into asynchronous mode is responsible for
ensuring the required thread safety constraints are maintained.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 51 days til DevNexus 2015
| 61 days til JavaLand 2015
| 71 days til CONFESS 2015