[wildfly-dev] EJB over HTTP

David M. Lloyd david.lloyd at redhat.com
Thu May 5 08:50:18 EDT 2016

I think this is a good idea.  Allowing the user to acquire a session ID 
could also allow for session-based authentication mechanisms to 
function.  And it could be optional, in the event that a user wants to 
(for example) rapid-fire stateless or one-way requests to a large number 
of balanced nodes.  It could also be expanded to cover the 
transaction/SFSB case we discussed, in that creation or acquisition of 
these things would reuse or create a new ID based on whether one was 

On 05/04/2016 09:59 PM, Stuart Douglas wrote:
> I have updated the spec doc to now use client side generated id that is
> paired with a session cookie to ensure uniqueness and node affinity.
> If the client does not already have a session id it can request one with
> an affinity message.
> Stuart
> On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>     On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas
>     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>         There are two problems with client generated ID's, and the main
>         one is that you can't guarantee that the cancellation message
>         will go to the same server as the original invocation. With my
>         current design the initial request will send back a JSESSIONID
>         that allows the cancel request to be targeted at the correct
>         server (of course if we already have affinity then this is not a
>         problem, but we can't guarantee that).
>         The other problem is that there is no easy way to guarantee
>         there will not be conflicts, although I guess you could send
>         back a 409 and force the client to retry with a new cancellation
>         id if a conflict happens. You can't really tie this to IP
>         because it may be behind a load balancer, and something like a
>         GUID may be expensive to generate for every invocation.
>     I just thought of a way to get around this. If we require the use of
>     an existing JSESSIONID for cancellable invocations both these
>     problems are resolved. The sticky session makes sure the correct
>     node is targeted, and the server can use the session id + invocation
>     id as a unique key.
>     The only overhead of this is that we could need some kind of
>     'affinity' request message that has no other purpose than generating
>     a session id if the client does not already have one (although this
>     would only need to be executed once).
>     Stuart
>         With the 1xx approach I am worried that not all load
>         balancers/proxies will properly support it. As this is not
>         really used outside of 'Expect: 100-continue' I would be
>         surprised if this works correctly without problems, even though
>         it is valid according to the spec.
>         Another potentially yucky way to do this would be to have the
>         client use chunked encoding and keep the request open, allowing
>         it to send some kind of cancellation token at any time. This
>         feels really hacky though.
>         Basically all the options suck, the one I put in the doc was
>         that one that I thought sucked the least when dealing with load
>         balancers.
>         Stuart
>         On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd
>         <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>             On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>             > Hi everyone,
>             >
>             > 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:
>             >https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>             >
>             > 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
>             > clustering).
>             >
>             > 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.
>             --
>             - DML
>             _______________________________________________
>             wildfly-dev mailing list
>             wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev


More information about the wildfly-dev mailing list