[jsr339-experts] Re: Should we remove _at_Suspend/Async?

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 12 Feb 2013 19:03:09 -0500

On 2/12/2013 6:15 PM, Jan Algermissen wrote:
> On 12.02.2013, at 23:29, Bill Burke <bburke_at_redhat.com> wrote:
>> I know Marek is gonna have a fit....but...funny things start to happen, at least on my end, when you start writing about these things and have to explain why this feature is useful...
>> So.....
>> Should we remove server-side async http support? What are the use cases for it?
>> 1. Long polling is perhaps the biggest one. The problem is, WebSockets and to a lesser extent Server-Sent-Events [1] have pretty much become *THE* way of setting up an event channel. HTTP Long polling is legacy. Believe me, I've tried to drum up interest in REST-based messaging, but WebSockets, et. al. pretty much has took over.
>> 2. Setting up priority-based request processing. i.e. putting CPU-intensive requests into a low-priority work queue.
>> 3. Implementing fire-and-forget. Immediately sending 202, Accepted to the client and re-using the servlet request thread to execute business logic.
> 4. Freeing the HTTP workers from dealing with blocking stuff (e.g. upstream calls) to avoid using them up until the server cannot handle any more requests

What you're saying is transfering work from one thread pool to another,
lower-priority thread pool. So, #4 is the same as #2. Even so, is that
such a big use case? I'm not saying it isn't, I just want to be
absolutely sure adding this feature is a good idea because we're going
to be maintaining/supporting it for a long long time.

Bill Burke
JBoss, a division of Red Hat