On May 4, 2016, at 1:12 PM, David M. Lloyd
On 05/04/2016 12:51 PM, Jason Greene wrote:
To me this is a configuration concern: the same issues arise for
REST-ish things. It's not really long polling per se (which usually
corresponds to using potentially infinitely long connections to
accommodate asynchronous requests or messages from server to client,
something we do not do), just a (possibly) long request (but no longer
than any typical REST request on a potentially slow resource). We don't
want or need a special one-off solution to this (general, long-standing)
issue in the context of EJB; any solution to this problem should be
general to all long requests.
The point of my proposals are that there is absolutely no need to
conflate the HTTP request lifecycle with EJB asynchronous invocation
semantics, and in fact doing so is actively harmful. All EJB request
types - sync and async - have a request and reply and conceptually could
be cancellable (even in the sync case the client may invoke
asynchronously or be cancelled), except for one-way invocations which
would immediately return a 202 status anyway. The only difference is in
whether the client thread directly waits for the response or whether it
waits via a Future, which the client can independently determine based
on information it already has locally. By the time the invocation gets
to the transport provider, the asynchronicity of the request has lost
its relevance; the transport provider is merely responsible for
conveyance of the request and response and possibly the cancel request
So really this is just about how we handle cancellation, and
cancellation is not a common case so we should optimize for requests
which aren't cancelled, which means one HTTP request and response per
EJB invocation with cancellation being somehow out-of-band.
I agree with you on this last point here for sure, with the added note that there are
arguably better ways to handle long running tasks than an async ejb method invocation.
That said there are certainly some interesting benefits to handling long running
invocations without holding a connection open. For example, if you have a transient
connection (like say a mobile network), you gain the benefit of never losing the response.
However, the necessity to limit resource overhead likely means a transient connection will
be unable to retrieve the response anyway, so again we are back to their are better ways
to handle long running tasks than an async ejb invocation.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat