Show Table of Contents
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.