[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
provided.
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
>
>
>
>
--
- DML
More information about the wildfly-dev
mailing list