[wildfly-dev] EJB over HTTP

[Stuart Douglas]

On Wed, May 4, 2016 at 11:15 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 05/04/2016 08:12 AM, Stuart Douglas wrote:
> >
> >
> > On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd at redhat.com
> > <mailto:david.lloyd at redhat.com>> wrote:
> >
> >     Getting transactions and SFSB to share a load-balancing behavior will
> >     hopefully be possible though.  I guess it'll require some thought to
> >     make it easy to avoid situations where (for example) two SFSB are
> spread
> >     to different nodes and then you try to create a UserTransaction which
> >     includes both.
> >
> >
> > Once you start using a SFSB or a Transaction you should get a session
> > cookie, which should give you affinity to the relevant node (based on
> > the assumption the load balancer supports sticky sessions).
>
> Yeah I was just thinking though: does that ID apply to all future
> invocations across all EJBs pointing at the node URL, or just EJB
> invocations on that SFSB/transaction for its lifetime?  It seems like
> you are suggesting that all invocations then get that session ID (which
> is probably OK, I just like to play devil's advocate whenever possible).
>

I am not 100% sure the best way to handle it. When a transaction or SFSB
session is open this makes sense, although once all sessions/transactions
has been closed there is no real reason to keep using the same session id
(at the moment there is no real way for the client to know that a SFSB is
gone though, maybe we need a response header to let a client know a
specified session is no longer valid).


>
> Also, there is an edge case where separate threads create SFSBs
> simultaneously which we'd want to ensure works as expected, in either case.
>

Yes, it should be possible to make this work as expected.

Stuart


>
> >
> > Stuart
> >
> >
> >     On 05/04/2016 05:36 AM, Stuart Douglas wrote:
> >     > The purpose is to enable load balancer based clustering to work.
> >     > Basically even though there is no underlying web session the
> JSESSIONID
> >     > cookie will make sure that the load balancer delivers the request
> to the
> >     > correct backend server.
> >     >
> >     > Basically existing load balancers already support sticky sessions,
> and
> >     > we are just piggy backing on that, as the primary customer use
> case for
> >     > this is allowing EJB calls through a HTTP load balancer.
> >     >
> >     > Stuart
> >     >
> >     > On Wed, May 4, 2016 at 7:56 PM, Tomaž Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>
> >     > <mailto:tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>>>
> wrote:
> >     >
> >     >     One thing that seems somewhat odd to me is the usage of
> JSESSIONID
> >     >     for tracking session state.
> >     >     That cookie/param is used for servlet http sessions and given
> that
> >     >     this is pure EJB without any servlets
> >     >     it would be bit confusing to require it. Or will this rely on
> >     >     session tracking from undertow-servlet?
> >     >
> >     >     --
> >     >     tomaz
> >     >
> >     >     On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas
> >     >     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com
> >
> >     <mailto:stuart.w.douglas at gmail.com
> >     <mailto:stuart.w.douglas at gmail.com>>> 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.
> >     >
> >     >         Stuart
> >     >
> >     >
> >     >
> >     >         _______________________________________________
> >     >         wildfly-dev mailing list
> >     >wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     <mailto:wildfly-dev at lists.jboss.org
> >     <mailto:wildfly-dev at lists.jboss.org>>
> >     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > 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
> >     _______________________________________________
> >     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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160505/99b43b46/attachment.html