18.3. Dead Connection Detection
18.3.1. Closing Dead Connection Resources on the Server
finally
block in the application's code.
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(); } }
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.
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.
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.
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.
18.3.2. Detecting Client Side Failure
client-failure-check-period
parameter then the client considers that the connection has failed. The client then initiates a failover or calls FailureListener
instances.
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.
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