jsr339-experts@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 04 Oct 2012 12:08:50 -0400

On 10/3/2012 7:21 PM, Marek Potociar wrote:
>
> 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.
>

Definitely not a bad practice. In the example you're freeing up the
client immediately and doing the work in the background without having
to spawn a thread or hand off to a work queue. Really simple code,
really simple solution. But, I'm not going to argue with you and will
just support it within our container.

Bill

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