Configuring Ranked Load Balancing in WildFly

One of the new features included in WildFly 18 is the ability to load balance requests using a ranked order of preference.

The default session affinity algorithm in a WilFly cluster is set by the “affinity” attribute:

/subsystem=undertow/configuration=filter/mod-cluster=load-balancer:read-resource()
{
    "outcome" => "success",
    "result" => {
        "advertise-frequency" => 10000,
         . . . .
        "affinity" => {"single" => undefined},
        "balancer" => undefined
    }
}

This means that, out of the box, web requests have an affinity for the member that last handled a given session. This option corresponds to traditional sticky session behavior.

By using ranked session affinity means that the WildFly is able to annotate the JSESSIONID with multiple routes, ranked in order of preference. Thus, if the primary owner of a given session is inactive, the load balancer can attempt to route the request to the next route in the list. This ensures that requests will be directed to the next best worker in the event that the primary owner is inactive, and prevents requests from “spraying” across the cluster.

The load balancer must be explicitly configured to enable support for parsing ranked routing; initially supporting Undertow-based load balancer.

When using WildFly as a load balancer ranked routing can be enabled with the following CLI command:

/subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:add

In this case, Web requests will have an affinity for the first available node in a list typically comprised of: primary owner, backup nodes, local node (if not a primary nor backup owner).