Not surprisingly, -1.
I believe we went over this several times together without being able to convince each other, so I'm not going to explain my reasons again - you can look it all up in the previous emails. Perhaps I can just mention that I agree with Sergey's and Jan's use cases. The current API provides basis for your other use cases (SSE, priority-based processing, "fire and forget" - or more precisely - "fire and retrieve result later").
Marek
On Feb 12, 2013, at 11: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?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com