Just a second...

Session replication

You can use session replication to ensure that if a client connection fails over from one server to another the state of the client session is maintained.

When a connection from a client through the load balancer to a Diffusion server fails, the load balancer routes the client connection to another Diffusion server. This server has access to the session and client information that is replicated in the datagrid.

Clients that connect to a specific Diffusion™ server and not through a load balancer cannot use session replication.

Figure 1. Session replication When a connection from a client through the load balancer to a Diffusion server fails, the load balancer routes the client connection to another Diffusion server. This server has access to the session and client information that is replicated in the datagrid.
  1. A client connects to a Diffusion server through a load balancer.

    The load balancer is configured to route based on the client's session ID and requests from the client go to the same server until that server becomes unavailable.

  2. Information about the client session is reflected into the datagrid.
    The following information is replicated:
    • session ID
    • session principal
    • session properties
    • list of topic selections
    The following information is not replicated and is created anew on the server a client fails over to:
    • session start time
    • statistics
    • client queue
  3. A client loses connection to the Diffusion server if the server becomes unavailable.
  4. The client can reconnect and the load balancer routes the connection to another Diffusion server.
  5. This Diffusion server has access to all of the client information shared into the datagrid by the first Diffusion server.
  6. The server uses the list of topic selections to recover the set of subscribed topics and subscribes the client to these topics.
  7. Subscribing the client to topics provides full value messages for all topics that contain the current topic state.

The client can reconnect to its session only if it reconnects within the reconnect time specified in the Connectors.xml configuration file. If the client does not reconnect within that time, the client session information is removed from the datagrid.

Considerations

Consider the following factors when using session replication:
  • Replication of session information into the datagrid is not automatic. It must be configured at the server.
  • Messages in transit are not preserved.
  • When a client session reconnects it does not need to authenticate again. The client uses a session token to reacquire its session. Ensure that this token is secure by using a secure transport to connect, for example, WSS.
  • The failover appears to the client as a disconnection and subsequent reconnection. To take advantage of high server availability, clients must implement a reconnect process.
  • The Diffusion server that a client reconnection attempt is forwarded to depends on your load balancer configuration. Sticky load balancing can be turned on to take advantage of reconnection or turned off to rely on session replication and failover.

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.