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
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.
A client connects to a Diffusion server through a
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.
Information about the client session is reflected into the
The following information is replicated:
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
A client loses connection to the Diffusion server
if the server becomes unavailable.
The client can reconnect and the load balancer routes the connection to
another Diffusion server.
This Diffusion server has access to all of the
client information shared into the datagrid by the first Diffusion server.
The server uses the list of topic selections to recover the set of
subscribed topics and subscribes the client to these topics.
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.
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:
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.
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
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.
To a client the process of disconnection and subsequent reconnection has the
following differences for session reconnection or session failover.
The client connects to the same Diffusion server it was previously
The client connects to a Diffusion
server different to the one it was previously connected
The client sends its
last session token to the server.
authenticates the client connection or validates its session
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
If lost messages cannot be recovered because
they are no longer present in a buffer, the server aborts
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
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