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