Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

18.3. Dead Connection Detection

18.3.1. Closing Dead Connection Resources on the Server

A HornetQ core or JMS client application must close its resources before it exits. You can configure your application to automatically close its resources by using the finally block in the application's code.
The following example shows a core client application which closes its session and session factory in a finally block: 
ServerLocator locator = null;
ClientSessionFactory sf = null;
ClientSession session = null;

try
{
   locator = HornetQClient.createServerLocatorWithoutHA(..);

   sf = locator.createClientSessionFactory();;

   session = sf.createSession(...);
   
   ... do some operations with the session...
}

finally
{
   if (session != null)
   {
      session.close();
   }
   
   if (sf != null)
   {
      sf.close();
   }

   if(locator != null)
   {
      locator.close();
   }
}
The following example shows a JMS client application which closes its session and session factory in a finally block: 
Connection jmsConnection = null;

try
{
   ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactoryWithoutHA(...);

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some operations with the connection...
}
finally
{
   if (connection != null)
   {
      connection.close();
   }
}
Using Connection Time to Live (TTL) Parameter

The connection-ttl parameter determines the time period for which the server keeps the connection alive when it does not receive data or ping packets from the client. This parameter ensures that dead server resources like old sessions are sustained longer thereby allowing clients to reconnect when a failed network connection recovers.

You can define connection TTL for JMS clients by specifying connection-ttl parameter in HornetQConnectionFactory instance. If you are deploying JMS connection factory instances direct into JNDI; you can define connection-ttl parameter in standalone.xml and domain.xml server configuration files.
The default value of connection-ttl parameter is 60000 milliseconds. If you do not need clients to specify their own connection TTL; you can define the connection-ttl-override parameter in server configuration files to override all values. The connection-ttl-override parameter is disabled by default and has a value of -1.
Garbage Collection

HornetQ uses garbage collection to detect and close the sessions which are not explicitly closed in a finally block. HornetQ server logs a warning similar to the warning shown below before closing the sessions: 

[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  I'm closing a ClientSession you left open. Please make sure you close all ClientSessions explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  The session you didn't close was created here:
java.lang.Exception
   at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
   at org.acme.yourproject.YourClass (YourClass.java:666)
The log message contains information about the code part where a JMS connection or user session was created and not closed later.

Report a bug

18.3.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 30000 milliseconds. A value of -1 means that the client will never close the connection if no data is received from the server.
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.
Report a bug