Marek,
thank you for this proposal. Here are my comments.
The targets of the asyn support, as described in the proposal, are: Response of JAX-RS method can be provided delayed (long after the JAX-RS method returned), and optionally non-blocking client invocations. I totally agree to that targets and both are valid and useful. But I do not agree to the rather complex solution that your proposal is providing. For me it looks as if your proposal more targets in providing pub/sub, which is not mentioned to be a target of the JAX-RS async support. Let me elaborate on this:
The target of decoupling can be reach rather easily:
@GET Future<MyEntity> getAsync() { /* Use Executor to return Future instance */ }
In case the return type is "Future<?>" the JAX-RS runtime can safely assume that the method will return without providing a physical result. The thread can return, and as soon as the Future is provided it can pick up work again and send back the response. No need for any additional complexity or annotations. If we want to give the server more control on the threads, we could add something like "getExecutorService()" to the context to prevent people from creating their own executors.
So, the question is: Do we need anything more complex like this? I actually would say "no" in the first draft, as e.g. COMET is not a target of JAX-RS 2.0 according to the project description on JCP.org (I would accept that complexity if COMET would be a target).
Another simple API would be:
@GET @Async MyEntity getAsync() { return new MyEntity(); }
This one could be just sugar that makes JAX-RS queue up the method execution, implicitly doing the same than above (use a singleton JAX-RS executor in standalone cases, or a container's executor service in Java EE cases, to produce a Future<?> by putting work on a queue). The question with this one would be: Why not putting *all* requests on a queue? We could omit @Async then, the user has no need to even think about it, and JAX-RS could internally decide by its own algorithm how to handle all responses in the queue. The API then would be exactly the same as for non-async calls.
So to keep things simple, I want to ask that we first reduce to this two simple proposals. If we see a need to support something more complex covered by our mission statement, we should then think over how to add that ontop of this simple API. I actually don't like to discuss a rather complex API from the top to bottom which already covers things not clearly part of our mission, which make the API more complex to use than actually needed.
For the non-blocking support I think this would be very valueable and we should add it to the API.
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Mittwoch, 20. Juli 2011 20:50
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] JAX-RS 2.0 API for asynchronous server-side
> request processing
>
> Hello experts,
>
> As announced last week, we have moved the asynchronous server-side
> processing API in front of some other topics in the
> schedule. I have wrote up a wiki page[1] discussing the problem domain
> in which I am also including some motivating
> examples, initial requirements and open topics to start the expert
> discussion.
>
> Please read through the wiki page[1] and send your thoughts to the EG
> list. Also, feel free to add new sections,
> reference links, requirements or open topics to the document, just make
> sure to mark the additions with your name.
>
> Let's shoot for finishing the first round of collecting the initial EG
> feedback on Friday (July 29) next week.
>
> Thank you,
> Marek
>
> [1] http://java.net/projects/jax-rs-
> spec/pages/AsyncServerProcessingModel