The EJB /HTTP protocol allows an EJB client application to use HTTP as a transport between the client and server. Among the original goals for the protocol (described here: Wildfly HTTP client wire spec) was the ability to work with a load balancer.

In the case of an EJB client invoking on SFSB and SLSB deployed in a cluster behind a load balancer, we expect generally the following behavior: 

• stickyness
  • invocations on SLSBs should be balanced across the cluster 
  • SFSB session creation operations should be balanced across the cluster  
  • invocations on SFSBs should be sticky to to the backend node their session was created on
• failover
  • invocations on a SFSB should failover to another backend node when the backend node on which their session was created is no longer available (from undeployment or server crash) 

Recent testing with Undertow+mod_cluster as a load balancer has shown that such stickiness does not seem to be happening and that, instead, all invocations sent to a given load balancer target are sticky to one backend node only. Likewise, failover does also not work as expected and a NoSuchEJBException is returned instead of the invocation failing over to an other available backend node.

Which backend node an EJB invocation request is sticky (or not sticky) to is managed by the HttpTargetContext for the load balancer target in question and JSESSIONIDs are used to manage the stickiness. It appears that the HttpTargetContext is not taking into account the type of bean upon which the invocation being made when managing stickiness.

This problem can be fixed by some relatively small adjustment of the way in which JSESSIONIDs are assigned to HTTP requests and a proof of concept was created to demonstrate this.

However, a larger problem is that the HttpTargetContext is shared between the three protocols EJB/HTTP, JNDI/HTTP and Transaction/HTTP and each of these protocols have different requirements for stickiness. For example, in the case of transactions, because transaction state is not replicated around the cluster, transactions involving one or more subordinates must be sticky to the node the subordinate was created on. This complicates any kind of solution to the problem.