Just a second...

Session failover

Session failover occurs when a client that disconnects from a Diffusion™ server attempts to connect to a different Diffusion server that also has information about that client's session.

For session failover to occur, session replication must be configured for a cluster of Diffusion servers. For more information, see Configuring replication.

Differences between session reconnection and session failover

When a client loses a load-balanced connection to Diffusion, one of the following things can occur when the client attempts to reconnect through the load balancer:
Session reconnection
The load balancer forwards the client connection to the Diffusion server it was previously connected to, if that server is still available. For more information, see Reconnect to the Diffusion server.
Session failover
The load balancer forwards the client connection to a different Diffusion server that shares information about the client's session, if session replication is enabled between the servers.

Prefer session reconnection to session failover wherever possible by ensuring that the load balancer is configured to route all connections from a specific client to the same server if that server is available.

Session reconnection is more efficient as less data must be sent to the client and has less risk of data loss, as sent messages can be recovered, in-flight requests are not lost, and handlers do not need to be registered again.

For more information, see Routing strategies at your load balancer.

To a client the process of disconnection and subsequent reconnection has the following differences for session reconnection or session failover.
Session reconnection Session failover
The client connects to the same Diffusion server it was previously connected to. The client connects to a Diffusion server different to the one it was previously connected to.
The client sends its last session token to the server.
The server authenticates the client connection or validates its session token.
The server uses the session token to resynchronize the streams of messages between the server and client by resending any messages that were lost in transmission from a buffer of sent messages.

If lost messages cannot be recovered because they are no longer present in a buffer, the server aborts the reconnection.

The server uses the session token to retrieve the session state and topic selections from the datagrid.
The server sends any messages that have been queued since the session disconnected. The server uses the state to recover the session, uses the topic selections to match the subscribed topics, and sends the session the current topic value for each subscribed topic.

Any in-flight requests made by the client session to the previous server are cancelled and the client session is notified by a callback. All handlers, including authentication handlers and update sources, that the client session had registered with the previous server are closed and receive a callback to notify them of the closure.