>>>>> 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.
>>>>> On Tue, 9 Dec 2014 14:31:34 +0100, Greg Wilkins <gregw_at_intalio.com> said:
GW> I'm +1000000 on Stuarts concern about multiple threads dispatched into the
GW> filter/servlet chain at the same time.
I see two viewpoints here.
* AsyncIsTheAppsProblem: this viewpoint says we don't need to protect
the app from any trouble they may get into by going async.
* AsyncProtectionIsUseful: this viewpoint acknowledges that Servlet has
always been in the business of providing thread protection, and it
should continue to be so in an async mode.
GW> Originally the async servlet design was done not for async IO. It's design
GW> was primarily motivated by startAsync() to AsyncContext.dispatch() style
GW> handling, so that all request handling and response generation was still to
GW> be done within a container thread dispatched to the filter/servlet using
GW> blocking APIs.
GW> This design was modified to support the startAsync() to
GW> AsyncContext.complete() style of usage where the asynchronous thread writes
GW> the response and then calls complete. The problem is that we never
GW> really well defined what methods on the request/response can be safely
GW> called by such asynchronous threads.
GW> We have now added async IO as a further extension this start->complete
GW> style, but still have not well defined what methods can be called. I think
GW> if we add asynchronous concurrent calls to the filter/servlet then we will
GW> have a real mess.
I see where you're coming from, Greg. I feel like were are just on the
edge of that mess now, if not starting to be in it already. Let me get
some time on Shing-Wai's calendar so I can get a better handle on these
concerns.
[...]
GW> We have gone to considerable lengths to ensure only a single thread
GW> is ever dispatched to the servlet container (eg onWritePossible and
GW> onReadPossible are delayed until the original thread exits the
GW> container). So I don't think we can realistically throw this all
GW> away and suddenly allow arbitrary threads to be simultaneously
GW> calling the filter/servlet
I see it is inappropriate to call this CLOSED, so I am reopening it in
the Subject:
>>>>> On Tue, 9 Dec 2014 19:08:37 +0100, Greg Wilkins <gregw_at_intalio.com> said:
GW> Yet I think our response to this has to be to tighten the
GW> specification rather than liberalise it. Then we need to look at
GW> the specific use-case that has raised this and see how we can best
GW> support that use-case without breaking some fundamental assumptions
GW> in the servlet design.
That seems like a reasonable way to make progress, and now is a very
good time for it.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 50 days til DevNexus 2015
| 60 days til JavaLand 2015
| 70 days til CONFESS 2015