<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 11:15 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/04/2016 08:12 AM, Stuart Douglas wrote:<br>
><br>
><br>
> On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a><br>
</span><span class="">> <mailto:<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>>> wrote:<br>
><br>
> Getting transactions and SFSB to share a load-balancing behavior will<br>
> hopefully be possible though. I guess it'll require some thought to<br>
> make it easy to avoid situations where (for example) two SFSB are spread<br>
> to different nodes and then you try to create a UserTransaction which<br>
> includes both.<br>
><br>
><br>
> Once you start using a SFSB or a Transaction you should get a session<br>
> cookie, which should give you affinity to the relevant node (based on<br>
> the assumption the load balancer supports sticky sessions).<br>
<br>
</span>Yeah I was just thinking though: does that ID apply to all future<br>
invocations across all EJBs pointing at the node URL, or just EJB<br>
invocations on that SFSB/transaction for its lifetime? It seems like<br>
you are suggesting that all invocations then get that session ID (which<br>
is probably OK, I just like to play devil's advocate whenever possible).<br></blockquote><div><br></div><div>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).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, there is an edge case where separate threads create SFSBs<br>
simultaneously which we'd want to ensure works as expected, in either case.<br></blockquote><div><br></div><div>Yes, it should be possible to make this work as expected.<br><br></div><div>Stuart<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> Stuart<br>
><br>
><br>
> On 05/04/2016 05:36 AM, Stuart Douglas wrote:<br>
> > The purpose is to enable load balancer based clustering to work.<br>
> > Basically even though there is no underlying web session the JSESSIONID<br>
> > cookie will make sure that the load balancer delivers the request to the<br>
> > correct backend server.<br>
> ><br>
> > Basically existing load balancers already support sticky sessions, and<br>
> > we are just piggy backing on that, as the primary customer use case for<br>
> > this is allowing EJB calls through a HTTP load balancer.<br>
> ><br>
> > Stuart<br>
> ><br>
> > On Wed, May 4, 2016 at 7:56 PM, Tomaž Cerar <<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a> <mailto:<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a>><br>
</span><span class="">> > <mailto:<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a> <mailto:<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a>>>> wrote:<br>
> ><br>
> > One thing that seems somewhat odd to me is the usage of JSESSIONID<br>
> > for tracking session state.<br>
> > That cookie/param is used for servlet http sessions and given that<br>
> > this is pure EJB without any servlets<br>
> > it would be bit confusing to require it. Or will this rely on<br>
> > session tracking from undertow-servlet?<br>
> ><br>
> > --<br>
> > tomaz<br>
> ><br>
> > On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas<br>
> > <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a> <mailto:<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>><br>
</span>> <mailto:<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a><br>
<span class="">> <mailto:<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi everyone,<br>
> ><br>
> > I have started looking into support for service invocation over<br>
> > HTTP. Unlike our existing HTTP upgrade support this will map EJB<br>
> > requests/responses directly to HTTP requests and responses,<br>
> > which should allow it to be used behind existing load balancers.<br>
> ><br>
> > I have started an initial description of the protocol at:<br>
> ><a href="https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc" rel="noreferrer" target="_blank">https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc</a><br>
> ><br>
> > The intention is to follow HTTP semantics as closely as<br>
> > possible. Clustering will be provided in a similar manner to web<br>
> > clustering (i.e. it will require a load balancer, and work in a<br>
> > similar manner to web clustering).<br>
> ><br>
> > There is still plenty work that needs to be done (especially<br>
> > around security), so if anyone has any feedback let me know.<br>
> ><br>
> > Stuart<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > wildfly-dev mailing list<br>
> ><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
</span>> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<span class="">> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>>><br>
> ><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > wildfly-dev mailing list<br>
</span>> ><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
<span class="">> ><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> ><br>
><br>
> --<br>
> - DML<br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
</span>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
><br>
<br>
--<br>
- DML<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div></div></blockquote></div><br></div></div>