20.4.2. Detecting Client Side Failure
The client application automatically sends ping packets to the server to prevent the client from shutting down. In a similar way, the client application considers the connection alive as long as it receives data from the server.
If the client does not receive data packets from the server for a time period specified by
client-failure-check-period
parameter then the client considers that the connection has failed. The client then initiates a failover or calls FailureListener
instances.
For JMS clients, client failure check period is configured using
ClientFailureCheckPeriod
attribute on HornetQConnectionFactory
instance. If you are deploying JMS connection factory instances directly into JNDI on the server side, you can specify client-failure-check-period
parameter in standalone.xml
and domain.xml
server configuration files.
The default value for client failure check period is 3000 milliseconds. A value of -1 means that the client will never close the connection if no data is received from the server. The value of client failure check period is much lower than connection TTL so that clients can reconnect in case of a transition failure.
Configuring Asynchronous Connection Execution
By default, packets received on the server side are executed on the remoting thread. It is possible to free up the remoting thread by processing operations asynchronously on any thread from the thread pool. You can configure asynchronous connection execution using async-connection-execution-enabled
parameter in standalone.xml
and domain.xml
server configuration files. The default value of this parameter is "true".
Note
If you process operations asynchronously on any thread from the thread pool, it adds a little latency. Short running operations are always handled on the remoting thread for performance reasons.