Chapter 17. 失效连接的检测

本章将讨论连接的生存时间(TTL)以及HornetQ如何处理出现故障的客户端或者异常退出的客户端(即客户端在 退出时没有合理的关闭相关资源)。

17.1. 服务器端对失效连接的清除

当客户端的应用程序退出时,应该关闭所使用的资源。在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,HornetQConnectionFactoryConnectionTTL 属性是用来定义连接的存活时间的。如果你将JMS连接工厂部署到JNDI中,则应使用配置文件中的connection-ttl参数来定义连接的TTL。

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

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

17.1.1. 关闭没有被成功关闭的核心会话或JMS连接

如前所述,在使用完毕后在finally中将所有的核心会话或JMS连接关闭是十分重要的。

如果你没有这样做,HornetQ会在拉圾回收时进行检测并会在日志中打印类似以下的警告(如果是JMS则在警告中 是相应的JMS连接):

                
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  I'm closin
g 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 sessi
on 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)    
                
            

HornetQ然后将未关闭的连接/会话关闭。

注意在日志的警告中还给出了创建JMS连接/客户端会话的具体行号,以便准确地确定出错的地方。

17.2. 客户端的故障检测

前面讲述了客户端如何向服务器发送ping以及服务器端如何清理失效的连接。发送ping还有另外一个目的,就是能 让客户端检测网络或服务器是否出现故障。

从客户端的角度来看,只要客户端能从一个连接不断接收服务器的数据,那么这个连接就被认为是一个有效的连接。

如果在属性client-failure-check-period所定义的时间内(单位毫秒)客户端没有 收到任何数据,客户端就认为这们连接发生了故障。根据不同的配置,客户端在这种情况下要么进行failover,要么 调用FailureListener的接口(或者是JMS的ExceptionListener)。

如果使用JMS,这个参数是HornetQConnectionFactoryClientFailureCheckPeriod。 如果你向JNDI部署JMS连接工厂,那么相应的参数在hornetq-jms.xml配置文件中,参数名 为client-failure-check-period

这个参数的默认值是30000毫秒,即半分钟。-1表示客户端不检查 连接的有效性。即不论是否有数据来自服务器,连接都一直有效。这一参数通常要比服务器端的连接TTL小许多,以使 客户端在出现短暂连接故障的情况下可以与服务器成功地重新连接。

17.3. 配置异步连接任务执行

默认情况下,服务器接收到的数据包被远程模块的线程处理。

为了避免远程模块的线程被长时间占用,数据包可以转给另外的一个线程池来处理。要注意这样做的增加了一些时间延迟。 因此如果数据包处理耗时很少,还是由远程模块线程来处理较好。 要配置这样的异步连接很行任务,将hornetq-configuration.xml文件中的 async-connection-execution-enabled 参数设为true (默认值是 true)。