On 05/04/2016 12:50 AM, Stuart Douglas wrote:
I have started looking into support for service invocation over HTTP.
Unlike our existing HTTP upgrade support this will map EJB
requests/responses directly to HTTP requests and responses, which should
allow it to be used behind existing load balancers.
I have started an initial description of the protocol at:
The intention is to follow HTTP semantics as closely as possible.
Clustering will be provided in a similar manner to web clustering (i.e.
it will require a load balancer, and work in a similar manner to web
There is still plenty work that needs to be done (especially around
security), so if anyone has any feedback let me know.
One thing I noticed is that you went a different way with async
invocations and cancellation support.
The way I originally proposed was that the request/response works as per
normal, but a 1xx header is used to send the client a cancellation token
which can be POSTed back to the server to cancel the invocation. I
understand that this approach requires 1xx support which some clients
might not have.
In your proposal, the async EJB request always returns immediately and
uses an invocation ID which can later be retrieved. I rejected this
approach because it requires the server to maintain state outside of the
request - something that is sure to fail. Also the client doesn't
really have any notion as to when it can GET the response: it would have
to do it more or less immediately to avoid a late response (or when
Future.get() is called), meaning you need two round trips in the common
case, which is not so good.
I think that the best compromise solution is to treat async invocations
identically to regular invocations, and instead let the *client* give a
cancellation ID to the server, which it can later POST to the server as
I described in my original document. If the server receives the
client's ID (maybe also matching the client's IP address) then the
request can be canceled if it is still running.
Failing this I still prefer the 1xx approach where the server gives a
cancellation ID at the beginning of the request, as this avoids problems
where the server has to maintain large object state for indefinite
amounts of time. Either of these two options means only one server
round trip for async invocation, and no server-side caching of responses.