users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Should we remove @Suspend/Async?

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 12 Feb 2013 17:30:55 -0500

On 2/12/2013 5:29 PM, Bill Burke 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] http://www.w3.org/TR/2011/WD-eventsource-20110208/

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com