No, I have never seen a (standard) loadbalancing policy that balance by checking load on the system.
IMHO it will have too much effort, each call must check all cluster nodes to decide which is the best one.
RoundRobin and Random try the nodes as the name is.
The FirstAvailable provide a connection to one cluster node related to the strategy (roundrobin or random) and stay with it as long as this node works.
If it is not longer available a new node is provided related to the stategie.
sorry for the late reply
At first, what i meant was a bit different and i also know about the different strategies. D0ue to the fact it can happen that a user connected to a server x could produce a massive load with some functionallity. If the policy is firstavailable, will it probably take this server again? What happens in case of roundRobin with a server that has 100% load and still gets "bombed" with requests. In this case, server x would cause i growing delay to the following client requests even in cases the other nodes have only 20% load.
Btw. in load-balancing tests, it can be observed that in e.g. RoundRobin fashions, only the first clusterSize-1 values are delayed. can that be explained with caching?
Set it per annoptation for the bean (in this case stateless) and if you need replication, just uncomment the @CacheConfig and set it for your needs.
The load-balancing strategy can be changed according to the ones written above.
/* RoundRobin = One node after another
* RandomRobin = One after another in a random order
* FirstAvailableIdenticalAllProxies = Same target node for all EJB's for this client (Sticky)
* FirstAvailable = Selects the first available target and sticks to it (Sticky) */
//@CacheConfig(name="sfsb/async", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)