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.
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(a)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(a)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/wi...
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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev