[wildfly-dev] EJB over HTTP

[Jason Greene]

> On May 4, 2016, at 1:12 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> 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 
> message.
> 
> 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