Broker 10.5 | webMethods Broker Documentation | webMethods Broker Messaging Programmer's Guide | JMS Policy Based Client-Side Clustering | Cluster Load Balancing Policies | How Does the Sticky Policy Work?
 
How Does the Sticky Policy Work?
If the cluster connection factory is configured using a sticky policy, when the Broker configured for distributing the messages goes offline, the next available Broker listed in the sequence of clustered Brokers will receive all subsequent messages. The following figure illustrates this process, using an example with a failover cluster consisting of three Brokers.
Selection Logic Used in Client-Side Failover
The numbered labels in the figure list the sequence of events occurring when a Broker becomes non-operational.
Label
Description
1
Broker A goes offline. webMethods API for JMS throws a connection exception and JMS client application catches the connection exception and reconnects.
2
The failover mechanism searches for the next available Broker in the cluster to which messages can be routed; this is Broker B.
3
Subsequent messages are routed to Broker B. Even if the Broker A comes back online, the messages will continue to be sent to Broker B.
When Broker A comes back online, Broker A will be included in the list of available Brokers for message distribution. If Broker B experiences an outage or if the publisher client re-establishes the connection to the cluster, the messages are routed back to Broker A.
4
No messages are routed to Broker C until Broker B experiences an outage and Broker A is also not available.