users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: AsyncResponse should be able to accept responses immediately

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 3 Oct 2012 16:21:36 -0700

On Oct 1, 2012, at 10:48 AM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 9/28/2012 2:21 PM, Marek Potociar wrote:
>>
>> On Sep 27, 2012, at 10:49 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>>
>>> On 9/27/2012 10:30 AM, Sergey Beryozkin wrote:
>>>> It is really the responsibility of the runtime to make sure the
>>>> invocation can be properly suspended - but not at the cost of preventing
>>>> the user from reacting to AsyncResponse immediately.
>>>>
>>>
>>> +1. For example this is a nice use case:
>>>
>>> @POST
>>> void expensiveOperation(AsyncResponse res, Data data) {
>>> res.resume(Response.status(202));
>>>
>>> ... process data
>>>
>>> }
>>
>> Note that the above cannot be covered by spec unless we introduce @ManagedAsync or similar annotation or unless we mandate that all async operations have to be invoked in a separate thread. I'm against such restriction, so if we found a use case that would convince you that @ManagedAsync is useful, then great!
>>
>
> I don't understand...The idea is, res.resume() above sends back a response to the client immediately, then we just continue. Dont' see what it has to do with @ManagedAsync. I also don't understand your references to a "separate thread" there's no separate thread needed here, that's the point...

The main idea behind async processing is to make sure the I/O container threads are not blocked while waiting for the response. The example above keeps blocking the container thread even after the client connection that the thread was serving has been closed. That's a really bad practice IMO and I don't think we should support it in our API as such. It would be a different story with managed async, of course.

Marek

>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com