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
Isn't that the killer use case in a world outside non-blocking, single threaded servers?
Jan
>
>
> With #1 being legacy, and #3 being a questionable practice, does #2 really justify having this complicated feature within JAX-RS 2.0? maybe there's some additional use cases I"m not seeing? Maybe the callbacks add some additional value?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com