The current draft doesn't define the relationship between the Non-Blocking API of 3.1 and the asynchronous processing feature of Servlet 3.0. It is clear that ReadListener and WriteListener will be invoked from additional threads, but it's not clear how the initial thread will be released from an application perspective? Is the registration of a ReadListener and/or WriteListener the signal to leave the response open? If so how will a Filter know that async processing started? In Servlet 3.0, any code on the initial thread can call request.isAsyncStarted() to find out. What's the equivalent with the Non-Blocking API?
It has been mentioned that Filters will only be called on the initial thread. That doesn't work always. For example a Filter that adds an ETag header needs to be involved at the very end of processing. Such a filter should be able to work work with any async request regardless of how it started. Why should Read/WriteListener not be able dispatch through an AsyncContext? If not then Read/WriteListener would have to take on a lot more responsibility than just reading and writing by definition.
There are other overlapping concepts. Like the AsyncListener and the sematnics for dealing with timeouts. How will timeouts be handled with the Non-Blocking API?
I do hope we end up with one consistent API for async requests. It would make sense for the Non-Blocking API to build on the async processing feature in 3.0. Would it be too radical to suggest that ReadListener and WriteListener should be registered through an instance of AsyncContext, and that an AsyncListener should provide the same callbacks for any async request including non-blocking reads and writes, and that a Read/WriteListener should be able to dispatch through an AsyncContext?
As one example, a request might start with non-blocking reads, followed by a dispatch through an AsyncContext to continue processing, followed by non-blocking writes, and then a dispatch for end-of-request processing. AsyncListener callbacks would apply and the semantics for dealing with timeouts are already known.
Rossen
----- Original Message -----
> From: "Greg Wilkins" <gregw_at_intalio.com>
> To: users_at_servlet-spec.java.net
> Sent: Wednesday, July 4, 2012 8:46:46 AM
> Subject: [servlet-spec users] Re: One more clarification
>
> Filip,
>
> I think the idea is that these APIs also work with the upgrade
> mechanism.
>
> But I generally agree that they really should be associated with
> startAsync. Perhaps if you want an async upgrade you do a startAsync
> and then trigger the upgrade mechanism.... I'll have to refresh my
> brain about how the upgrade is intended to work.
>
> cheers
>
>
>
>
> On 4 July 2012 00:02, Filip Hanik (mailing lists)
> <devlists_at_hanik.com> wrote:
> > I'm struggling a bit with the ideas of these callback methods, and
> > I think
> > it's a simple matter of clarification.
> >
> > When would these methods ever be called unless there is an
> > AsyncContext
> > going on for that request? (meaning thread has been detached from
> > request/response)?
> >
> > Ie, should setReadListener(....) throw IllegalStateException unless
> > there is
> > an AsyncContext ?
> > Same for setWriteListener
> >
> > Ie, it doesn't make sense to have a call back if I'm already using
> > up a
> > thread
> > for a request, and the only way to not have that thread is by
> > having an
> > Async servlet
> >
> > Best
> > Filip
> >
> >
> >
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com>
> www.webtide.com
> Developer advice, services and support
> from the Jetty & CometD experts.
>