[hornetq-commits] JBoss hornetq SVN: r9061 - branches/HnetQ_323_cn/docs/user-manual/zh.
do-not-reply at jboss.org
do-not-reply at jboss.org
Tue Apr 6 06:03:01 EDT 2010
Author: gaohoward
Date: 2010-04-06 06:03:01 -0400 (Tue, 06 Apr 2010)
New Revision: 9061
Modified:
branches/HnetQ_323_cn/docs/user-manual/zh/connection-ttl.xml
Log:
done
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/connection-ttl.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/connection-ttl.xml 2010-04-06 09:46:56 UTC (rev 9060)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/connection-ttl.xml 2010-04-06 10:03:01 UTC (rev 9061)
@@ -17,17 +17,14 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="connection-ttl">
- <title>Detecting Dead Connections</title>
- <para>In this section we will discuss connection time-to-live (TTL) and explain how HornetQ
- deals with crashed clients and clients which have exited without cleanly closing their
- resources.</para>
+ <title>失效连接的检测</title>
+ <para>本章将讨论连接的生存时间（TTL）以及HornetQ如何处理出现故障的客户端或者异常退出的客户端（即客户端在
+ 退出时没有合理的关闭相关资源）。</para>
<section id="dead.connections">
- <title>Cleaning up Dead Connection Resources on the Server</title>
- <para>Before a HornetQ client application exits it is considered good practice that it
- should close its resources in a controlled manner, using a <literal>finally</literal>
- block.</para>
- <para>Here's an example of a well behaved core client application closing its session and
- session factory in a finally block:</para>
+ <title>服务器端对失效连接的清除</title>
+ <para>当客户端的应用程序退出时，应该关闭所使用的资源。在<literal>finally</literal>进行资源的关闭
+ 是一个很好的方法。</para>
+ <para>下面的例子中，一个Hornet客户端在finally中关闭了它的会话（session）和会话工厂（session factory）：</para>
<programlisting>
ClientSessionFactory sf = null;
ClientSession session = null;
@@ -53,7 +50,7 @@
}
}
</programlisting>
- <para>And here's an example of a well behaved JMS client application:</para>
+ <para>下面的例子给出了一个JMS客户端是如何适当关闭相关资源的：</para>
<programlisting>
Connection jmsConnection = null;
@@ -73,47 +70,31 @@
}
}
</programlisting>
- <para>Unfortunately users don't always write well behaved applications, and sometimes
- clients just crash so they don't have a chance to clean up their resources!</para>
- <para>If this occurs then it can leave server side resources, like sessions, hanging on the
- server. If these were not removed they would cause a resource leak on the server and
- over time this result in the server running out of memory or other resources.</para>
- <para>We have to balance the requirement for cleaning up dead client resources with the fact
- that sometimes the network between the client and the server can fail and then come
- back, allowing the client to reconnect. HornetQ supports client reconnection, so we
- don't want to clean up "dead" server side resources too soon or this will prevent any
- client from reconnecting, as it won't be able to find its old sessions on the
- server.</para>
- <para>HornetQ makes all of this configurable. For each <literal
- >ClientSessionFactory</literal> we define a <emphasis>connection TTL</emphasis>.
- Basically, the TTL determines how long the server will keep a connection alive in the
- absence of any data arriving from the client. The client will automatically send "ping"
- packets periodically to prevent the server from closing it down. If the server doesn't
- receive any packets on a connection for the connection TTL time, then it will
- automatically close all the sessions on the server that relate to that
- connection.</para>
- <para>If you're using JMS, the connection TTL is defined by the <literal
- >ConnectionTTL</literal> attribute on a <literal>HornetQConnectionFactory</literal>
- instance, or if you're deploying JMS connection factory instances direct into JNDI on
- the server side, you can specify it in the xml config, using the parameter <literal
- >connection-ttl</literal>.</para>
- <para>The default value for connection ttl is <literal>60000</literal>ms, i.e. 1 minute. A
- value of <literal>-1</literal> for <literal>ConnectionTTL</literal> means the server
- will never time out the connection on the server side.</para>
- <para>If you do not wish clients to be able to specify their own connection TTL, you can
- override all values used by a global value set on the server side. This can be done by
- specifying the <literal>connection-ttl-override</literal> attribute in the server side
- configuration. The default value for <literal>connection-ttl-override</literal> is
- <literal>-1</literal> which means "do not override" (i.e. let clients use their own
- values).</para>
+ <para>然而有时候资源在客户端得不到合理的关闭。有的客户端应用在结束时忘记了关闭资源，有的客户端有时发生故障导致
+ 程序突然中断，相关资源也没有来得及关闭！</para>
+ <para>如果上述情况发生了，那么这些资源就会留在服务器端而不会被清理。这就会造成资源泄漏现象并最終导致服务器内存
+ 溢出或其它资源的溢出错误。</para>
+ <para>因此在服务器端要有某种机制来避免资源的泄漏。也就是对无效资源进行回收。在判断什么是无效资源时，HornetQ
+ 考虑到了客户端重新连接的情况。就是当一个连接由于网络临时中断后又恢复正常时，客户端有可能通过不断重试
+ 成功地连接到服务器端。如果服务器端过早清除了相关的连接资源，则客户端就可能重试失败。</para>
+ <para>HornetQ的资源回收是完全可配置的。每个 <literal
+ >ClientSessionFactory</literal> 有一个<emphasis>连接 TTL</emphasis>的参数。
+ 这个参数的意义是当客户端的一个连接没有任何数到达服务器时，服务器充许这个连接有效的最长时间。客户端通过定
+ 时向服务器端发送“ping“数据包来维持连接的有效，以免被服务器关掉。如果服务器在TTL指定的时间内没有收到任何
+ 数据包，则认为该连接无效，继而关闭与该连接相关的所有的会话（session）。</para>
+ <para>如果使用JMS，<literal>HornetQConnectionFactory</literal>的<literal>ConnectionTTL</literal>
+ 属性是用来定义连接的存活时间的。如果你将JMS连接工厂部署到JNDI中，则应使用配置文件中的<literal
+ >connection-ttl</literal>参数来定义连接的TTL。</para>
+ <para>默认的连接TTL值是<literal>60000</literal>毫秒，即一分钟。 <literal>ConnectionTTL</literal>
+ 设为<literal>-1</literal>表示服务器永远不检测超时的连接。</para>
+ <para>如果你不想让客户端来规定连接存活时间（TTL），你可以在服务器端的配置文件中定义
+ <literal>connection-ttl-override</literal>属性。它的默认值是<literal>-1</literal>，表示
+ 服务器端该属性无效（即客户端可以定义自己的连接TTL）。</para>
<section>
- <title>Closing core sessions or JMS connections that you have failed to close</title>
- <para>As previously discussed, it's important that all core client sessions and JMS
- connections are always closed explicitly in a <literal>finally</literal> block when
- you are finished using them. </para>
- <para>If you fail to do so, HornetQ will detect this at garbage collection time, and log
- a warning similar to the following in the logs (If you are using JMS the warning
- will involve a JMS connection not a client session):</para>
+ <title>关闭没有被成功关闭的核心会话或JMS连接</title>
+ <para>如前所述，在使用完毕后在<literal>finally</literal>中将所有的核心会话或JMS连接关闭是十分重要的。</para>
+ <para>如果你没有这样做，HornetQ会在拉圾回收时进行检测并会在日志中打印类似以下的警告（如果是JMS则在警告中
+ 是相应的JMS连接）：</para>
<programlisting>
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession] I'm closin
@@ -126,48 +107,33 @@
at org.acme.yourproject.YourClass (YourClass.java:666)
</programlisting>
- <para>HornetQ will then close the connection / client session for you.</para>
- <para>Note that the log will also tell you the exact line of your user code where you
- created the JMS connection / client session that you later did not close. This will
- enable you to pinpoint the error in your code and correct it appropriately.</para>
+ <para>HornetQ然后将未关闭的连接／会话关闭。</para>
+ <para>注意在日志的警告中还给出了创建JMS连接／客户端会话的具体行号，以便准确地确定出错的地方。</para>
</section>
</section>
<section>
- <title>Detecting failure from the client side.</title>
- <para>In the previous section we discussed how the client sends pings to the server and how
- "dead" connection resources are cleaned up by the server. There's also another reason
- for pinging, and that's for the <emphasis>client</emphasis> to be able to detect that
- the server or network has failed.</para>
- <para>As long as the client is receiving data from the server it will consider the
- connection to be still alive. </para>
- <para>If the client does not receive any packets for <literal
- >client-failure-check-period</literal> milliseconds then it will consider the
- connection failed and will either initiate failover, or call any <literal
- >FailureListener</literal> instances (or <literal>ExceptionListener</literal>
- instances if you are using JMS) depending on how it has been configured.</para>
- <para>If you're using JMS it's defined by the <literal>ClientFailureCheckPeriod</literal>
- attribute on a <literal>HornetQConnectionFactory</literal> instance, or if you're
- deploying JMS connection factory instances direct into JNDI on the server side, you can
- specify it in the <literal>hornetq-jms.xml </literal> configuration file, using the
- parameter <literal>client-failure-check-period</literal>.</para>
- <para>The default value for client failure check period is <literal>30000</literal>ms, i.e.
- 30 seconds. A value of <literal>-1</literal> means the client will never fail the
- connection on the client side if no data is received from the server. Typically this is
- much lower than connection TTL to allow clients to reconnect in case of transitory
- failure.</para>
+ <title>客户端的故障检测</title>
+ <para>前面讲述了客户端如何向服务器发送ping以及服务器端如何清理失效的连接。发送ping还有另外一个目的，就是能
+ 让客户端检测网络或服务器是否出现故障。</para>
+ <para>从客户端的角度来看，只要客户端能从一个连接不断接收服务器的数据，那么这个连接就被认为是一个有效的连接。</para>
+ <para>如果在属性<literal>client-failure-check-period</literal>所定义的时间内（单位毫秒）客户端没有
+ 收到任何数据，客户端就认为这们连接发生了故障。根据不同的配置，客户端在这种情况下要么进行failover，要么
+ 调用<literal>FailureListener</literal>的接口（或者是JMS的<literal>ExceptionListener</literal>）。</para>
+ <para>如果使用JMS，这个参数是<literal>HornetQConnectionFactory</literal>的<literal>ClientFailureCheckPeriod</literal>。
+ 如果你向JNDI部署JMS连接工厂，那么相应的参数在<literal>hornetq-jms.xml</literal>配置文件中，参数名
+ 为<literal>client-failure-check-period</literal>。</para>
+ <para>这个参数的默认值是<literal>30000</literal>毫秒，即半分钟。<literal>-1</literal>表示客户端不检查
+ 连接的有效性。即不论是否有数据来自服务器，连接都一直有效。这一参数通常要比服务器端的连接TTL小许多，以使
+ 客户端在出现短暂连接故障的情况下可以与服务器成功地重新连接。</para>
</section>
<section id="connection-ttl.async-connection-execution">
- <title>Configuring Asynchronous Connection Execution</title>
- <para>By default, packets received on the server side are executed on the remoting
- thread.</para>
- <para>It is possible instead to use a thread from a thread pool to handle some packets so
- that the remoting thread is not tied up for too long. However, please note that
- processing operations asynchronously on another thread adds a little more latency.
- Please note that most short running operations are always handled on the remoting thread for performance reasons.
-
- To enable asynchronous connection execution, set the parameter <literal
- >async-connection-execution-enabled</literal> in <literal
- >hornetq-configuration.xml</literal> to <literal>true</literal> (default value is
- <literal>true</literal>).</para>
+ <title>配置异步连接任务执行</title>
+ <para>默认情况下，服务器接收到的数据包被远程模块的线程处理。</para>
+ <para>为了避免远程模块的线程被长时间占用，数据包可以转给另外的一个线程池来处理。要注意这样做的增加了一些时间延迟。
+ 因此如果数据包处理耗时很少，还是由远程模块线程来处理较好。
+
+ 要配置这样的异步连接很行任务，将<literal>hornetq-configuration.xml</literal>文件中的
+ <literal>async-connection-execution-enabled</literal> 参数设为<literal>true</literal>
+ （默认值是 <literal>true</literal>）。</para>
</section>
</chapter>
More information about the hornetq-commits
mailing list