On Wed, May 4, 2016 at 11:15 PM, David M. Lloyd <david.lloyd@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@redhat.com
> <mailto:david.lloyd@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@gmail.com <mailto:tomaz.cerar@gmail.com>
>     > <mailto:tomaz.cerar@gmail.com <mailto:tomaz.cerar@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@gmail.com <mailto:stuart.w.douglas@gmail.com>
>     <mailto:stuart.w.douglas@gmail.com
>     <mailto:stuart.w.douglas@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@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>     <mailto:wildfly-dev@lists.jboss.org
>     <mailto:wildfly-dev@lists.jboss.org>>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev