Hi Markus,
Many thanks for reviewing the paper. Please see my responses inlined.
On 07/24/2011 02:11 PM, Markus KARG wrote:
> Marek,
>
> thank you for this proposal. Here are my comments.
It's just a motivation paper at the moment, not a proposal. The proposal will come once I receive some initial EG
feedback on the subj.
>
> 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 paper evolved in the process o writing, so I did start with some basic assumptions about the requirements and use
cases and later moved in the direction of covering the features and scenarios that I found useful. Pub/sub is one of
them - it's just a special case of UC2 ("response is provided as a result of an asynchronous event").
>
> 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.
Does it mean that some JAX-RS thread has to be blocked while waiting for the response? Also, if we decide to go with
your simplified proposal, how would you later evolve it into something suitable for a Pub/Sub support?
> 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.
IMHO, this may certainly be useful but I can also imagine people want to use their own ES in many async cases. Would
that be possible?
>
> 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).
Not all pub/sub scenarios need to use Comet. Scenario in which one or more requests are waiting for another request from
another client to resume seems quite common.
>
> 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.
I was thinking about the solution above too, but it seems to fail to satisfy decoupling the request processing from the
framework threads. Since there is no notion of executor service as a resource in JavaEE yet, I'm not sure how we could
effectively tell the framework to use a user-configured and managed ES via annotations.
>
> 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.
Again, this is not a proposal yet. This paper tries to provide the background for what we need to consider as part of
the proposal. But I would discourage from splitting the async server-side topic into two. We would keep a list of
requirements in the topic and decide which requirements will be covered and which not.
At the same time, I fail to see how the topics, including pub/sub, covered in the paper go beyond our mission statement.
From the JSR:
"This JSR will specify a simple asynchronous request processing model such that a response can be returned asynchronous
to the request. ..."
>
> For the non-blocking support I think this would be very valueable and we should add it to the API.
What are the use cases that the async client API cannot sufficiently cover?
To get a better picture, can you provide a discussion with some examples how we could support this feature? Feel free to
add a new page to the wiki and reference it from the existing page...
Thanks,
Marek
>
> 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
>