Ranked routing

In  clustering

Overview

When the primary owner of a given session is inactive (from the load balancer’s perspective), the load balancer will route requests for that session to some other node, based on its own balancing logic. However, when a non-owner processes the request it will auto-correct the route to direct the next request to the primary owner. This feature enables the ability to annotate the JSESSIONID with multiple routes, ranked in order of preference. Thus, if the primary owner of a given session is inactive (from the load balancer’s perspective), 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.

When configured to use RANKED routing, the route will contain:

  1. The primary owner

  2. The backup owners

  3. The local node (if not already present)

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

Requirements

Hard Requirements

  • Add new RANKED routing strategy option to the distributed session manager configuration.

  • Fallback to OWNER routing strategy logic if cache in non-distributed.

  • Add parsing support in the proxy implementation when WildFly is used as a load balancer.

Nice-to-Have Requirements

Non-Requirements

Test Plan

  • Add unit test to verify RouteLocator behavior when routing strategy is RANKED

  • Clustering testsuite will contain integration test that validates routing

  • Add a full-scope integration test (including load balancer and cluster of application servers) that validates failover behavior to backup owners (tests integration code in Undertow (UNDERTOW-1432, WFLY-12144) and mod_cluster (MODCLUSTER-673))

Community Documentation

Community documentation will be updated to include RANKED routing server and load balancer configuration.