On Nov 7, 2012, at 9:09 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>
>>>> 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:
>>
>
> To paint this as a fact is misleading. You have your own opinion here that is definitely not shared by myself.
Now you guys are confusing me :-)
The whole point of the async for cases like this is IIUC to have the threads in one thread pool execute similar tasks.
Bills example uses the HTTP handling thread (presumably from a dedicated HTTP handler threadpool) to do the long running task.
@Bill, why do you think your's is 'better' than handing the long running task to another thread, especially one from a different thread pool?
Jan
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com