On Nov 7, 2012, at 8:14 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On Nov 7, 2012, at 7:59 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>>
>> On 11/7/2012 11:50 AM, Jan Algermissen wrote:
>>> Hi,
>>>
>>> do you have an estimate what the overhead of using an AsyncResponse is, if you send back a sync. response for the majority of cases?
>>>
>>> Use Case:
>>>
>>> Implement a resource method that retains the opportunity for handling a request asynchronously but decides thatonly when the method is actually invoked. IOW, when the method determines that a synchronous response is fine, it simply invokes the async response right away.
>>>
>>> Does that significanly affect performance or resource usage?
>>
>> I don't know. I could do a mini bench vs. JBoss Web Servlet container, but I"m too lazy.
>>
>> BTW, I have a similar use case that I've discussed before:
>>
>> @POST
>> void post(@Suspended AsyncResponse res) {
>>
>> res.resume(Response.status(202).build()); // 202, Accepted
>>
>> // do an expensive op.
>>
>> }
>>
>> In this case, the client gets a response immediately, while the server does something in the background. Really simple, no need for queues, threads, etc.
>
> Well, yes that is how you do async properly with HTTP :-)
No, it is not. Assuming the the code above runs in the same container thread that is dedicated to processing incoming requests, in the code above you return the response to the client quickly, but you will still continue to occupy the request processing container thread for your long-runnning operation effectively cancelling out any positive effect of the async operation on the server-side.
To do it right, you would have to do this instead:
@POST
void post(@Suspended AsyncResponse res) {
res.resume(Response.status(202).build()); // 202, Accepted
// submit an expensive op. to be executed in another thread
}
HTH,
Marek
>
> Jan
>
>
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>