Chapter 32. Client Reconnection and Session Reattachment

HornetQ clients can be configured to automatically reconnect or re-attach to the server if a failure is detected in the server-client connection.

32.1. 100% Transparent session re-attachment

If failure is transient (that is, due to a temporary network failure) and the target server was not restarted, sessions will still exist on the server as long as the connection-ttl has not expired (see Chapter 15, Detecting Dead Connections for details about connection-ttl).
In this case, HornetQ automatically re-attaches the client sessions to the server sessions when the connection reconnects. This is done 100% transparently and the client can continue as before.
As HornetQ clients send commands to their servers, they store each sent command in an in-memory buffer. When connection failure occurs and the client re-attaches to its server, the server passes the ID of the last command it successfully received back to the client as part of the re-attachment protocol. If the client had attempted to send any other commands, it can resend those commands from its buffer so that client and server can reconcile their differences.
The ConfirmationWindowSize parameter (typically set in the <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/jms-ra.rar/META-INF/ra.xml file) defines the size of the buffer in bytes. When the server has received ConfirmationWindowSize bytes of commands and processed them it will send back a command confirmation to the client. The client can then remove confirmed commands from the buffer.
Setting ConfirmationWindowSize to -1 (default) disables buffering and prevents re-attachment from occurring, forcing reconnect instead.
If you are using JMS, and the JMS service on the server is being used to load your JMS connection factory instances into JNDI, then uncomment the ConfirmationWindowSize parameter in the <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/jms-ra.rar/META-INF/ra.xml file. If you are using JMS, but not JNDI, set these values directly on the HornetQConnectionFactory instance with the appropriate setter method. If you are using Core, you can set these values directly on the ClientSessionFactory instance with the appropriate setter method.