[jax-rs-spec users] [jsr339-experts] Re: Re: Overhead of AsyncResponse

From: Bill Burke <>
Date: Wed, 07 Nov 2012 15:32:04 -0500

On 11/7/2012 3:17 PM, Jan Algermissen wrote:
> On Nov 7, 2012, at 9:09 PM, Bill Burke <> 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?

I don't have a problem with saying this is 'better' or not. I do have a
problem with saying that this is wrong, because its not. Defining and
configuring multiple thread pools can be a burden on both the admin and
developer, not to mention the extra code the developer has to write.

Bill Burke
JBoss, a division of Red Hat