On Feb 12, 2013, at 5:29 PM, 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.
>
>
> 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?
>
-1
Although SSE and WS are the future in this space, this isn't going to happen overnight. Those organizations that are still using older versions of Java aren't going to switch to WS tomorrow. Async in JAX-RS is another tool for the box.
-- Santiago