[jboss-cvs] JBossAS SVN: r83987 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Feb 9 02:14:36 EST 2009
Author: xhuang at jboss.com
Date: 2009-02-09 02:14:36 -0500 (Mon, 09 Feb 2009)
New Revision: 83987
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
update
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_JBoss_Cache_JGroups.po 2009-02-09 06:16:39 UTC (rev 83986)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_JBoss_Cache_JGroups.po 2009-02-09 07:14:36 UTC (rev 83987)
@@ -9,7 +9,7 @@
"Project-Id-Version: Clustering_Guide_JBoss_Cache_JGroups\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-06 15:22+1000\n"
+"PO-Revision-Date: 2009-02-09 17:14+1000\n"
"Last-Translator: Xi HUANG\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -1493,7 +1493,7 @@
msgid ""
"timeout specifies how long to wait for a response from the suspected member "
"before considering it dead."
-msgstr ""
+msgstr "timeout 指定在把可疑节点当成已崩溃节点之前等待响应的时间。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:500
@@ -1508,7 +1508,7 @@
"FD and FD_SOCK, each taken individually, do not provide a solid failure "
"detection layer. Let's look at the the differences between these failure "
"detection protocols to understand how they complement each other:"
-msgstr ""
+msgstr "FD 和 FD_SOCK 都不提供完整的失效切换检测层。让我们看看这些失效切换检测协议的区别，并理解它们是如何互补的。"
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:505
@@ -1520,13 +1520,13 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:510
#, no-c-format
msgid "An overloaded machine might be slow in sending are-you-alive responses."
-msgstr ""
+msgstr "超载的机器发送 are-you-alive 响应的速度可能会比较慢。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:515
#, no-c-format
msgid "A member will be suspected when suspended in a debugger/profiler."
-msgstr ""
+msgstr "当成员在 debugger/profiler 里被挂起时，它将成为可疑成员。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:520
@@ -1534,19 +1534,19 @@
msgid ""
"Low timeouts lead to higher probability of false suspicions and higher "
"network traffic."
-msgstr ""
+msgstr "设置较低的超时时间会导致出现假可疑节点的更高可能性和更高的网络负载。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:525
#, no-c-format
msgid "High timeouts will not detect and remove crashed members for some time."
-msgstr ""
+msgstr "设置较高的超时时间将不能及时地检测和删除已崩溃的成员。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:532
#, no-c-format
msgid "<emphasis>FD_SOCK</emphasis>:"
-msgstr ""
+msgstr "<emphasis>FD_SOCK</emphasis>："
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:538
@@ -1554,25 +1554,25 @@
msgid ""
"Suspended in a debugger is no problem because the TCP connection is still "
"open."
-msgstr ""
+msgstr "在 debugger 里挂起不会出现问题，因为它的 TCP 连接仍然有效。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:543
#, no-c-format
msgid "High load no problem either for the same reason."
-msgstr ""
+msgstr "基于相同的原因，高负载也不会有问题。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:548
#, no-c-format
msgid "Members will only be suspected when TCP connection breaks"
-msgstr ""
+msgstr "只有 TCP 连接断开时，成员才会成为可疑成员。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:557
#, no-c-format
msgid "So hung members will not be detected."
-msgstr ""
+msgstr "所以，挂起的成员不会被检测到。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:562
@@ -1581,7 +1581,7 @@
"Also, a crashed switch will not be detected until the connection runs into "
"the TCP timeout (between 2-20 minutes, depending on TCP/IP stack "
"implementation)."
-msgstr ""
+msgstr "而且，直到连接出现 TCP 超时（2 - 20分钟，这取决于不同的 TCP/IP 栈的实现）时，崩溃节点才会被检测到。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:569
@@ -1589,7 +1589,7 @@
msgid ""
"The aim of a failure detection layer is to report real failures and "
"therefore avoid false suspicions. There are two solutions:"
-msgstr ""
+msgstr "失效切换检测层的目的是报告实时故障并避免检测到假的可疑节点。有两个方案："
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:574
@@ -1604,7 +1604,7 @@
"So, the first solution would be to lower the timeout value for KEEP_ALIVE. "
"This can only be done for the entire kernel in most operating systems, so if "
"this is lowered to 15 minutes, this will affect all TCP sockets."
-msgstr ""
+msgstr "在缺省情况下，JGroups 配置 FD_SOCK 套接字为 KEEP_ALIVE，这表示如果在两小时内没有通信的话，TCP 将发送一个 heartbeat。如果某个主机崩溃了（或中间开关或路由器崩溃）且没有正确关闭 TCP 连接，我们会在两小时（再多几分钟）后检测到。这当然比从不关闭连接（如果 KEEP_ALIVE 为 off）要好，但也帮助不大。所以对于 KEEP_ALIVE 选项，第一个方案将降低超时时间。在大部分操作系统里，这只能对于整个内核进行修改，所以如果降低到 15 分钟，这会影响到所有的 TCP 套接字。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:579
@@ -1616,7 +1616,7 @@
"message if the socket was closed abnormally. However, in the case of a "
"crashed switch or host, FD will make sure the socket is eventually closed "
"and the suspect message generated. Example:"
-msgstr ""
+msgstr "第二个方案是合并 FD_SOCK 和 FD；你可以设置 FD 的超时时间，所以它比 TCP 超时时间要低得多，且可以对于每个进程进行配置。如果套接字非正常关闭，FD_SOCK 将已经生成了一个可疑消息。然而，在主机或开关崩溃的情况下，FD 将确保套接字最终被关闭且生成可疑消息。例如："
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:584
@@ -1627,6 +1627,10 @@
"<FD timeout=\"10000\" max_tries=\"5\" shun=\"true\" \n"
"down_thread=\"false\" up_thread=\"false\" /> ]]>"
msgstr ""
+"<![CDATA[\n"
+"<FD_SOCK down_thread=\"false\" up_thread=\"false\"/>\n"
+"<FD timeout=\"10000\" max_tries=\"5\" shun=\"true\" \n"
+"down_thread=\"false\" up_thread=\"false\" /> ]]>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:586
@@ -1639,7 +1643,7 @@
"seconds. Note that with this example, if you have your system stopped in a "
"breakpoint in the debugger, the node you're debugging will be suspected "
"after ca 50 seconds."
-msgstr ""
+msgstr "当和邻居节点通信的套接字被异常关闭时（如因为操作系统关闭所有套接字导致的进程崩溃），它将怀疑该成员。然而，当主机或交换机崩溃时，套接字不会被关闭，因此，作为第二层保险措施，FD 将在 50 秒后挂起该邻居节点。请注意，在这个例子里，如果你让系统停在 Debugger 里的一个断点上，你所调试的节点将在 50 秒后被挂起。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:589
@@ -1648,7 +1652,7 @@
"A combination of FD and FD_SOCK provides a solid failure detection layer and "
"for this reason, such technique is used accross JGroups configurations "
"included within JBoss Application Server."
-msgstr ""
+msgstr "因此，FD 和 FD_SOCK 的组合提供了一个坚实的失效切换检测层，JGroups 配置以及 JBoss 应用服务器都使用了这样的技术。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:598
@@ -1658,7 +1662,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:599
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"Reliable delivery protocols within the JGroups stack ensure that data "
"pockets are actually delivered in the right order (FIFO) to the destination "
@@ -1681,7 +1685,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:607
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The UNICAST protocol is used for unicast messages. It uses ACK. It is "
"configured as a sub-element under the JGroups Config element. If the JGroups "
@@ -1690,16 +1694,18 @@
"example configuration for the <literal>UNICAST</literal> protocol."
msgstr ""
"UNICAST 协议用于单播信息。它使用 ACK。它被配置成 JGroups <literal>Config</"
-"literal> 元素下的一个子元素。这里有一个配置 <literal>UNICAST</literal> 协议的"
+"literal> 元素下的一个子元素。如果 JGroups 栈配置为 TCP 传输协议，因为 TCP 自身保证了单播消息的 FIFO 传递，设置 UNICAST 协议就没有必要了。这里有一个配置 <literal>UNICAST</literal> 协议的"
"例子。"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:610
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<UNICAST timeout=\"100,200,400,800\"\n"
"down_thread=\"false\" up_thread=\"false\"/>"
-msgstr "<UNICAST timeout=\"100,200,400,800\"/>"
+msgstr ""
+"<UNICAST timeout=\"100,200,400,800\"\n"
+"down_thread=\"false\" up_thread=\"false\"/>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:612
@@ -1749,7 +1755,7 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:633
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<pbcast.NAKACK max_xmit_size=\"60000\" use_mcast_xmit=\"false\" \n"
" \n"
@@ -1757,10 +1763,11 @@
" discard_delivered_msgs=\"true\"\n"
" down_thread=\"false\" up_thread=\"false\"/>"
msgstr ""
-"<pbcast.NAKACK\n"
-" max_xmit_size=\"8192\"\n"
-" use_mcast_xmit=\"true\" \n"
-" retransmit_timeout=\"600,1200,2400,4800\"/>"
+"<pbcast.NAKACK max_xmit_size=\"60000\" use_mcast_xmit=\"false\" \n"
+" \n"
+" retransmit_timeout=\"300,600,1200,2400,4800\" gc_lag=\"0\"\n"
+" discard_delivered_msgs=\"true\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:636
@@ -1819,13 +1826,11 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:661
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">gc_lag specifies</emphasis> the number of messages "
"garbage collection lags behind."
-msgstr ""
-"<emphasis role=\"bold\">NumAcceptThreads</emphasis>：用来接受客户联接的线程的"
-"数量。它的缺省值是 1。"
+msgstr "<emphasis role=\"bold\">gc_lag specifies</emphasis>：垃圾收集发生之前所允许的消息数目。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:672
@@ -1871,7 +1876,7 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:684
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<pbcast.GMS print_local_addr=\"true\"\n"
" join_timeout=\"3000\"\n"
@@ -1882,9 +1887,10 @@
msgstr ""
"<pbcast.GMS print_local_addr=\"true\"\n"
" join_timeout=\"3000\"\n"
-" down_thread=\"false\" \n"
+" down_thread=\"false\" up_thread=\"false\"\n"
" join_retry_timeout=\"2000\"\n"
-" shun=\"true\"/>"
+" shun=\"true\"\n"
+" view_bundling=\"true\"/>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:688
@@ -1953,7 +1959,7 @@
"JOIN or LEAVE request arriving at the same time are bundled and handled "
"together at the same time, only sending out 1 new view / bundle. This is is "
"more efficient than handling each request separately."
-msgstr ""
+msgstr "<emphasis role=\"bold\">view_bundling</emphasis> 指定同时到达的多个 JOIN 或 LEAVE 请求是否同时进行捆绑和处理，而只发送一个新的视图/捆绑。这比单独捆绑每个请求更为高效。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:720
@@ -1990,14 +1996,14 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:732
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<FC max_credits=\"1000000\"\n"
"down_thread=\"false\" up_thread=\"false\" \n"
" min_threshold=\"0.10\"/>"
msgstr ""
"<FC max_credits=\"1000000\"\n"
-" down_thread=\"false\" \n"
+"down_thread=\"false\" up_thread=\"false\" \n"
" min_threshold=\"0.10\"/>"
#. Tag: para
@@ -2048,14 +2054,14 @@
"received after 5 seconds, then it sends an explicit credit request to the "
"receivers whose credits are currently below 0, until it receives credits "
"from all members whose credits are below 0."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_block_time</emphasis> 指定发送者阻塞的最长时间（毫秒）。如果发送者阻塞了，且在 5 秒后没有接收到任何 credit，它将向目前 credit 低于 0 的接收者发送一个显性 credit 请求，直到它从所有 credit 低于 0 的成员接收到 credit 为止。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:755
#: Clustering_Guide_JBoss_Cache_JGroups.xml:816
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Note"
-msgstr "备注"
+msgstr "注意"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:756
@@ -2071,13 +2077,13 @@
"receiver can keep up with. TCP flow control only takes into account "
"individual node communications and has not a notion of who's the slowest in "
"the group, which is why FC is required."
-msgstr ""
+msgstr "使用同步组 RPC 调用的应用程序在其 JGroups 协议栈里不要求 FC 协议，因为在同步通信里，调用线程在等待所有成员响应时阻塞，这已经降低了调用的速度。即使 TCP 自身提供了流量控制，对于基于 TCP 的 JGroups 栈来说 FC 也是必需的，因为对于组通信，我们都得以最慢的接收者可以处理的最高速度发送组消息。TCP 流量控制只考虑单独节点的通信且不会注意组里哪个节点最慢，这就是为什么需要 FC 的原因。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:762
#, no-c-format
msgid "Why is FC needed on top of TCP ? TCP has its own flow control !"
-msgstr ""
+msgstr "为什么 TCP 还需要 FC？既然 TCP 具有自己的流量控制机制！"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:763
@@ -2093,7 +2099,7 @@
"group, it is possible that A, B and C receive the 100M, but D only received "
"1M messages. (BTW: this is also the reason why we need NAKACK, although TCP "
"does its own retransmission)."
-msgstr ""
+msgstr "原因在于组通信，我们得以最慢的接收者可以处理的最高速度发送组消息。假设我们有一个群集 {A,B,C,D}。D 较慢（可能是超载），其他节点比较快。当 A 发送一个组消息，它建立了一个 TCP 连接 A-A（概念上的）、A-B、A-C 和 A-D（如果它们还不存在）。所以，假设 A 往群集发送 1 亿条消息，因为 TCP 的流量控制只适用于 A-B、A-C 和 A-D，但不适用于 A-{B,C,D}，这里的 {B,C,D} 是一个组，可能 A、B 和 C 接收了 1 亿条消息，但 D 只接收了一百万条。（顺便提一句，这也是我们为什么需要 NAKACK 的原因，既然 TCP 自己实现中继）。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:767
@@ -2106,7 +2112,7 @@
"done by the STABLE protocol, which can be configured to run the stability "
"protocol round time based (e.g. every 50s) or size based (whenever 400K data "
"has been received)."
-msgstr ""
+msgstr "现在，当原来的发送者 S 崩溃且节点请求中继 S 的消息时，JGroups 得把所有的消息缓冲在内存里。因为所有的成员都缓冲它们所接收的消息，它们不时需要删除 stable 消息（等于所有成员都可以看到的消息）。这是由 STABLE 协议来完成的，我们可以配置它根据时间间隔（如每隔 50 秒）或数据大小（每当接收了 400K 数据）运行。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:770
@@ -2118,7 +2124,7 @@
"protocol in TCP will cause writes to block if the window is full - we assume "
"in the above case that this is still much faster for A-B and A-C than for A-"
"D."
-msgstr ""
+msgstr "如在上面的例子里，慢节点 D 将阻止组删除超过 1M 的消息，所以每个成员都将缓冲 99M 消息。这在大多数情况下都会导致 OOM 异常。请注意 - 虽然 TCP 里的 sliding window 协议将在窗口满了时写入到块 - 我们假设在上面的例子里 A-B 和 A-C 仍然比 A-D 快得多。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:773
@@ -2126,13 +2132,13 @@
msgid ""
"So, in summary, we need to send messages at a rate the slowest receiver (D) "
"can handle."
-msgstr ""
+msgstr "所以，总的来说，我们需要以最慢接收者（D）能处理的速度发送消息。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:779
#, no-c-format
msgid "So do I always need FC?"
-msgstr ""
+msgstr "那为什么我们总是需要 FC？"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:780
@@ -2142,11 +2148,12 @@
"the example above, if there was something about the application that would "
"naturally cause A to slow down its rate of sending because D wasn't keeping "
"up, then FC would not be needed."
-msgstr ""
+msgstr "这取决于应用程序怎样使用 JGroups 频道。参照上面的例子，如果因为 D 处理不过来，而应用程序会自然地让 A 发送消息的速度慢下来，那么就需要 FC。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:783
#, no-c-format
+#, fuzzy
msgid ""
"A good example of such an application is one that makes synchronous group "
"RPC calls (typically using a JGroups RpcDispatcher.) By synchronous, we mean "
@@ -2154,7 +2161,7 @@
"members of the group. In that kind of application, the threads on A that are "
"making calls would block waiting for responses from D, thus naturally "
"slowing the overall rate of calls."
-msgstr ""
+msgstr "这样的应用程序"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:786
More information about the jboss-cvs-commits
mailing list