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
http://bill.burkecentral.com