users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 27 Sep 2012 21:32:33 +0100

Hi
On 27/09/12 18:49, Bill Burke 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
>
> }
>
>> The other thing is that AsyncResponse should be able to accept 'null'
>> resumes, example, 204 in return to GET should work too - this makes it
>> difficult to use AsyncResponse.resume for the immediate provision of the
>> response.
>>
>> Thus I'd like to do a minor improvement:
>> - add AsyncResponse.accept(Object)
>
> accept == 202? I don't see why we'd need a special method. Its a rare
> case and there is a good chance you'll want to populate a Response
> object for a 202 anyways.
>
>

I think I may've made some wrong assumptions.
Basically I was thinking that by the time "expensiveOperation" was
invoked the invocation had not necessarily been suspended.

In fact this is how I've just implemented it. I think it works faster
for cases when a method receiving AsyncResponse may have something quite
immediately to return and if not then just return from the method
before persisting AsyncResponse reference.

However if we always have the invocation suspended before
expensiveOperation was invoked then immediate data return via
res.resume() works as expected and as such all is covered well...

I guess, assuming this is how all see it working, it might make sense
consider adding an "immediately" property to @Suspended - it is set by
default to true, but if is set to false - then the invocation is
suspended after the method return but only if an object was not provided
- that will be faster for cases I described above where a response can
be delivered back immediately without getting the invocation thread
going the rounds...If anyone sees any use in it - then it can be at
least tracked for 2.1, etc

Sergey