[hornetq-commits] JBoss hornetq SVN: r9163 - branches/HnetQ_323_cn/docs/user-manual/zh.
do-not-reply at jboss.org
do-not-reply at jboss.org
Mon Apr 26 08:51:28 EDT 2010
Author: gaohoward
Date: 2010-04-26 08:51:27 -0400 (Mon, 26 Apr 2010)
New Revision: 9163
Modified:
branches/HnetQ_323_cn/docs/user-manual/zh/client-reconnection.xml
Log:
done
Modified: branches/HnetQ_323_cn/docs/user-manual/zh/client-reconnection.xml
===================================================================
--- branches/HnetQ_323_cn/docs/user-manual/zh/client-reconnection.xml 2010-04-26 09:20:10 UTC (rev 9162)
+++ branches/HnetQ_323_cn/docs/user-manual/zh/client-reconnection.xml 2010-04-26 12:51:27 UTC (rev 9163)
@@ -17,104 +17,73 @@
<!-- permitted by applicable law. -->
<!-- ============================================================================= -->
<chapter id="client-reconnection">
- <title>Client Reconnection and Session Reattachment</title>
- <para>HornetQ clients can be configured to automatically reconnect or re-attach to the server in
- the event that a failure is detected in the connection between the client and the server. </para>
+ <title>客户端重新连接与会话恢复</title>
+ <para>通过配置，HornetQ的客户端在与服务器的连接出现故障时，可以自动地重新建立连接并恢复与服务器的通迅。</para>
<section>
- <title>100% Transparent session re-attachment</title>
- <para>If the failure was due to some transient failure such as a temporary network failure,
- and the target server was not restarted, then the sessions will still be existent on the
- server, asssuming the client hasn't been disconnected for more than connection-ttl <xref
- linkend="connection-ttl"/>.</para>
- <para>In this scenario, HornetQ will automatically re-attach the client sessions to the
- server sessions when the connection reconnects. This is done 100% transparently and the
- client can continue exactly as if nothing had happened.</para>
- <para>The way this works is as follows:</para>
- <para>As HornetQ clients send commands to their servers they store each sent command in an
- in-memory buffer. In the case that connection failure occurs and the client subsequently
- reattaches to the same server, as part of the reattachment protocol the server informs
- the client during reattachment with the id of the last command it successfully received
- from that client.</para>
- <para>If the client has sent more commands than were received before failover it can replay
- any sent commands from its buffer so that the client and server can reconcile their
- states.</para>
- <para>The size of this buffer is configured by the <literal>ConfirmationWindowSize</literal>
- parameter, when the server has received <literal>ConfirmationWindowSize</literal> bytes
- of commands and processed them it will send back a command confirmation to the client,
- and the client can then free up space in the buffer.</para>
- <para>If you are using JMS and you're using the JMS service on the server to load your JMS
- connection factory instances into JNDI then this parameter can be configured in <literal
- >hornetq-jms.xml</literal> using the element <literal
- >confirmation-window-size</literal> a. If you're using JMS but not using JNDI then
- you can set these values directly on the <literal>HornetQConnectionFactory</literal>
- instance using the appropriate setter method.</para>
- <para>If you're using core you can set these values directly on the <literal
- >ClientSessionFactory</literal> instance using the appropriate setter method.</para>
- <para>The window is specified in bytes, and has a default value of <literal
- >1MiB</literal>.</para>
- <para>Setting this parameter to <literal>-1</literal> disables any buffering and prevents
- any re-attachment from occurring, forcing reconnect instead. The default value for this
- parameter is <literal>-1</literal>.</para>
+ <title>100%透明的会话恢复（re-attachment）</title>
+ <para>如果网络出现暂时性连接故障，并且服务器没有重启的情况下，当前的会话还会存在服务器中，其状态如同客户端
+ 没有断开超过连接TTL<xref linkend="connection-ttl"/>时间。</para>
+ <para>在这种情况下，当客户端重新连接上服务器后，HornetQ自动将客户端和会话与服务器端的会话重新连接起来。整个过程
+ 对于客户端是完全透明的，在客户端就好像什么都没有发生一样。</para>
+ <para>具体工作原理如下：</para>
+ <para>客户端再向服务器发送命令时，它将每个命令保存到内存的一块缓存中。当连接出现故障时客户端会尝试与该服务
+ 器恢复会话。做为恢复协议的一部分，服务器在会话恢复时通知客户端最后一个成功接收的命令id。</para>
+ <para>根据这个命令id，客户端可以判断它的缓存中是否有命令还未被服务器成功接收。如果有，客户端可以重新发送
+ 这些命令。</para>
+ <para>缓存的大小由<literal>ConfirmationWindowSize</literal>参数决定。当服务器成功接收了
+ <literal>ConfirmationWindowSize</literal>字节的命令时，会向客户端发送一个命令确认，以使客户端
+ 及时清除缓存。</para>
+ <para>如果使用JMS服务，并且JMS的连接工厂是注册到JNDI的话，相应的参数是<literal
+ >hornetq-jms.xml</literal>文件中的<literal
+ >confirmation-window-size</literal>项。如果你并不将JMS连接工厂注册到JNDI，则你需要在
+ <literal>HornetQConnectionFactory</literal>上使用相应的方法直接设置该参数。</para>
+ <para>如果使用核心服务，你可以直接在<literal>ClientSessionFactory</literal>实例上直接设置该参数。</para>
+ <para>参数的单位是字节，默认值是<literal>1MiB</literal>。</para>
+ <para>如果该参数是值设为<literal>-1</literal>，则关闭缓存，即关闭了重新恢复功能，迫使进行重新连接。默认
+ 值是<literal>-1</literal>。</para>
</section>
<section>
- <title>Session reconnection</title>
- <para>Alternatively, the server might have actually been restarted after crashing or being
- stopped. In this case any sessions will no longer be existent on the server and it won't
- be possible to 100% transparently re-attach to them.</para>
- <para>In this case, HornetQ will automatically reconnect the connection and <emphasis
- role="italic">recreate</emphasis> any sessions and consumers on the server
- corresponding to the sessions and consumers on the client. This process is exactly the
- same as what happens during failover onto a backup server.</para>
- <para>Client reconnection is also used internally by components such as core bridges to
- allow them to reconnect to their target servers.</para>
- <para>Please see the section on failover <xref linkend="ha.automatic.failover"/> to get a
- full understanding of how transacted and non-transacted sessions are reconnected during
- failover/reconnect and what you need to do to maintain <emphasis role="italic">once and
- only once </emphasis>delivery guarantees.</para>
+ <title>会话重新连接</title>
+ <para>有时服务器发生故障后进行了重启。这时服务器将丢失所有当前的会话，上面所述的会话恢复就不能做到完全透明了。</para>
+ <para>在这种情况下，HornetQ自动地重新建立连接并<emphasis role="italic">重新创建</emphasis>会话
+ 和接收者。这一过程与向备份服务器进行失效备援（failover）完全一样。</para>
+ <para>客户重新连接的功能还用在其它一些模块上，如核心桥，以使它们能够重新连接到目标服务器上。</para>
+ <para>要全面理解事务性会话和非事务性会话在失效备援／重连接情况下的细节，以及如何保证<emphasis role="italic">
+ 一次并且只有一次</emphasis>的消息传递，请参见<xref linkend="ha.automatic.failover"/>的有关内容。</para>
</section>
<section>
- <title>Configuring reconnection/reattachment attributes</title>
- <para>Client reconnection is configured using the following parameters:</para>
+ <title>重新连接／会话恢复的配置参数</title>
+ <para>下面是客户端用于重新连接的参数：</para>
<itemizedlist>
<listitem>
- <para><literal>retry-interval</literal>. This optional parameter determines the
- period in milliseconds between subsequent reconnection attempts, if the
- connection to the target server has failed. The default value is <literal
- >2000</literal> milliseconds.</para>
+ <para><literal>retry-interval</literal>。可选参数。它决定了两次重新连接尝试间隔的时间。单位
+ 是毫秒。默认值是<literal>2000</literal>毫秒。</para>
</listitem>
<listitem>
- <para><literal>retry-interval-multiplier</literal>. This optional parameter
- determines determines a multiplier to apply to the time since the last retry to
- compute the time to the next retry.</para>
- <para>This allows you to implement an <emphasis>exponential backoff</emphasis>
- between retry attempts.</para>
- <para>Let's take an example:</para>
- <para>If we set <literal>retry-interval</literal> to <literal>1000</literal> ms and
- we set <literal>retry-interval-multiplier</literal> to <literal>2.0</literal>,
- then, if the first reconnect attempt fails, we will wait <literal>1000</literal>
- ms then <literal>2000</literal> ms then <literal>4000</literal> ms between
- subsequent reconnection attempts.</para>
- <para>The default value is <literal>1.0</literal> meaning each reconnect attempt is
- spaced at equal intervals.</para>
+ <para><literal>retry-interval-multiplier</literal>。可选参数。它表示下一次重试时间间隔的
+ 系数。即下一次重试的时间间隔是本次时间间隔乘以该参数。</para>
+ <para>这样可以实现重试间隔的<emphasis>指数延迟（exponential backoff）</emphasis>。</para>
+ <para>让我们看一个例子：</para>
+ <para>假设<literal>retry-interval</literal>为<literal>1000</literal> ms，并且我们
+ 将<literal>retry-interval-multiplier</literal>设为<literal>2.0</literal>，如果
+ 第一次尝试失败，则等待<literal>1000</literal>毫秒后进行第二次重试，如果再失败，则每三次重
+ 试要在<literal>2000</literal>毫秒后进行，第四次要等待<literal>4000</literal>毫秒，
+ 以此类推。</para>
+ <para>默认值是<literal>1.0</literal>，表示每次重试间隔相同的时间。</para>
</listitem>
<listitem>
- <para><literal>max-retry-interval</literal>. This optional parameter determines the
- maximum retry interval that will be used. When setting <literal
- >retry-interval-multiplier</literal> it would otherwise be possible that
- subsequent retries exponentially increase to ridiculously large values. By
- setting this parameter you can set an upper limit on that value. The default
- value is <literal>2000</literal> milliseconds.</para>
+ <para><literal>max-retry-interval</literal>。可选参数。它决定了重试间的最大时间间隔。
+ 使用<literal>retry-interval-multiplier</literal>可以使重试的时间间隔以指数级增加。
+ 有可能造成时间间隔增加到一个非常大的数值。通过设置一个最大值可对其增长进行限制。默认
+ 值是<literal>2000</literal>毫秒。</para>
</listitem>
<listitem>
- <para><literal>reconnect-attempts</literal>. This optional parameter determines the
- total number of reconnect attempts to make before giving up and shutting down. A
- value of <literal>-1</literal> signifies an unlimited number of attempts. The
- default value is <literal>0</literal>.</para>
+ <para><literal>reconnect-attempts</literal>。可先参数。它表示要进行多少重试后才放弃
+ 并退出。<literal>-1</literal>表示进行无限次重试。默认值是<literal>0</literal>。</para>
</listitem>
</itemizedlist>
- <para>If you're using JMS, and you're using the JMS Service on the server to load your JMS
- connection factory instances directly into JNDI, then you can specify these parameters
- in the xml configuration in <literal>hornetq-jms.xml</literal>, for example:</para>
+ <para>如果使用JMS并且将JMS的连接工厂绑定到JNDI服务中，则需要在<literal>hornetq-jms.xml</literal>
+ 文件中对这些参数进行配置，如下例所示：</para>
<programlisting>
<connection-factory name="ConnectionFactory">
<connectors>
@@ -130,23 +99,18 @@
<reconnect-attempts>1000</reconnect-attempts>
</connection-factory>
</programlisting>
- <para>If you're using JMS, but instantiating your JMS connection factory directly, you can
- specify the parameters using the appropriate setter methods on the <literal
- >HornetQConnectionFactory</literal> immediately after creating it.</para>
- <para>If you're using the core API and instantiating the <literal
- >ClientSessionFactory</literal> instance directly you can also specify the
- parameters using the appropriate setter methods on the <literal
- >ClientSessionFactory</literal> immediately after creating it.</para>
- <para>If your client does manage to reconnect but the session is no longer available on the
- server, for instance if the server has been restarted or it has timed out, then the
- client won't be able to re-attach, and any <literal>ExceptionListener</literal> or
- <literal>FailureListener</literal> instances registered on the connection or session
- will be called.</para>
+ <para>如果使用JMS但是直接实例化JMS连接工厂，你可以使用适当的方法在 <literal
+ >HornetQConnectionFactory</literal> 对象上直接设置这些参数。</para>
+ <para>如果使用核心接口直接创建 <literal
+ >ClientSessionFactory</literal>实例，则用它的适当的方法可以设置这些参数。</para>
+ <para>如果客户端重新连接后发现会话已经丢失（如服务器重启或超时），则无法完成恢复。如果在连接上或会话上注册了
+ <literal>ExceptionListener</literal>或<literal>FailureListener</literal>，
+ 它们将会被通知。</para>
</section>
<section id="client-reconnection.exceptionlistener">
<title>ExceptionListeners and SessionFailureListeners</title>
- <para>Please note, that when a client reconnects or re-attaches, any registered JMS <literal
- >ExceptionListener</literal> or core API <literal>SessionFailureListener</literal>
- will be called.</para>
+ <para>请注意当客户端进行重新连接或恢复会话时，注册的JMS <literal
+ >ExceptionListener</literal> 或核心接口的 <literal>SessionFailureListener</literal>
+ 将会被调用。</para>
</section>
</chapter>
More information about the hornetq-commits
mailing list