失效连接的检测

当客户端的应用程序退出时，应该关闭所使用的资源。在finally进行资源的关闭 是一个很好的方法。

下面的例子中，一个Hornet客户端在finally中关闭了它的会话（session）和会话工厂（session factory）：

ClientSessionFactory sf = null;ClientSession session = null;try{   sf = HornetQClient.createClientSessionFactory(...);   session = sf.createSession(...);      ... do some stuff with the session...}finally{   if (session != null)   {      session.close();   }      if (sf != null)   {      sf.close();   }}        

下面的例子给出了一个JMS客户端是如何适当关闭相关资源的：

Connection jmsConnection = null;try{   ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...);   jmsConnection = jmsConnectionFactory.createConnection();   ... do some stuff with the connection...}finally{   if (connection != null)   {      connection.close();   }}        

然而有时候资源在客户端得不到合理的关闭。有的客户端应用在结束时忘记了关闭资源，有的客户端有时发生故障导致 程序突然中断，相关资源也没有来得及关闭！

如果上述情况发生了，那么这些资源就会留在服务器端而不会被清理。这就会造成资源泄漏现象并最終导致服务器内存 溢出或其它资源的溢出错误。

因此在服务器端要有某种机制来避免资源的泄漏。也就是对无效资源进行回收。在判断什么是无效资源时，HornetQ 考虑到了客户端重新连接的情况。就是当一个连接由于网络临时中断后又恢复正常时，客户端有可能通过不断重试 成功地连接到服务器端。如果服务器端过早清除了相关的连接资源，则客户端就可能重试失败。

HornetQ的资源回收是完全可配置的。每个 ClientSessionFactory 有一个连接 TTL的参数。 这个参数的意义是当客户端的一个连接没有任何数到达服务器时，服务器充许这个连接有效的最长时间。客户端通过定 时向服务器端发送“ping“数据包来维持连接的有效，以免被服务器关掉。如果服务器在TTL指定的时间内没有收到任何 数据包，则认为该连接无效，继而关闭与该连接相关的所有的会话（session）。

如果使用JMS，HornetQConnectionFactory的ConnectionTTL 属性是用来定义连接的存活时间的。如果你将JMS连接工厂部署到JNDI中，则应使用配置文件中的connection-ttl参数来定义连接的TTL。

默认的连接TTL值是60000毫秒，即一分钟。 ConnectionTTL 设为-1表示服务器永远不检测超时的连接。

如果你不想让客户端来规定连接存活时间（TTL），你可以在服务器端的配置文件中定义 connection-ttl-override属性。它的默认值是-1，表示 服务器端该属性无效（即客户端可以定义自己的连接TTL）。

 

 

客户端配置需要在hornetq-jms.xml中添加connection-factory.connection-ttl属性

 

服务端配置需要在hornetq-configure.xml中添加connection-ttl-override属性