[jboss-cvs] JBossAS SVN: r87700 - projects/docs/enterprise/4.3.4/Server_Configuration_Guide/ja-JP.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Apr 22 22:35:53 EDT 2009
Author: tnagamot
Date: 2009-04-22 22:35:52 -0400 (Wed, 22 Apr 2009)
New Revision: 87700
Modified:
projects/docs/enterprise/4.3.4/Server_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
translated
Modified: projects/docs/enterprise/4.3.4/Server_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.4/Server_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po 2009-04-23 00:48:24 UTC (rev 87699)
+++ projects/docs/enterprise/4.3.4/Server_Configuration_Guide/ja-JP/Clustering_Guide_JBoss_Cache_JGroups.po 2009-04-23 02:35:52 UTC (rev 87700)
@@ -12,7 +12,7 @@
"Project-Id-Version: Clustering_Guide_JBoss_Cache_JGroups\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-03-16 01:28+0000\n"
-"PO-Revision-Date: 2009-04-21 16:46+1000\n"
+"PO-Revision-Date: 2009-04-23 12:35+1000\n"
"Last-Translator: Takuro Nagamoto <tnagamot at redhat.com>\n"
"Language-Team: ja-JP\n"
"MIME-Version: 1.0\n"
@@ -1709,7 +1709,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 の組み合わせにより、安定した障害検出レイヤが提供されます。このため、このテクニックは、JBoss Application Server 内にある JGroups の設定全体で使用されます。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:598
@@ -1719,7 +1719,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 "
@@ -1730,7 +1730,7 @@
msgstr ""
"JGroups スタック内の信頼できる配信プロトコルはデータパケットが実際に正しい順"
"序 (FIFO) で目的地となるノードに配信されるようにします。 positive および "
-"negative の配信確認が信頼できるメッセージ配信の基盤となります (ACK と NAK)。 "
+"negative の配信確認 (ACK と NAK) が信頼できるメッセージ配信の基盤となります 。 "
"ACK モードでは、 送信側が受信側からの確認が受信されるまでメッセージを再送しま"
"す。 NAK モードでは、 受信側がギャップを発見した場合に再送を要求します。"
@@ -1742,25 +1742,24 @@
#. 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 "
"stack is configured with TCP transport protocol, UNICAST is not necessary "
"because TCP itself guarantees FIFO delivery of unicast messages. Here is an "
"example configuration for the <literal>UNICAST</literal> protocol."
-msgstr ""
-"UNICAST プロトコルはユニキャストメッセージに使用されます。 ACK を使用しま"
-"す。 JGroups <literal>Config</literal> エレメント配下のサブエレメントとして"
-"設定されます。 次に <literal>UNICAST</literal> プロトコルの設定例を示します。"
+msgstr "UNICAST プロトコルはユニキャストメッセージに使用されます。 ACK を使用し、JGroups Config エレメントのサブメレメンとして設定されます。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
@@ -1772,7 +1771,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:615
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">timeout</emphasis> specifies the retransmission "
"timeout (in milliseconds). For instance, if the timeout is \"100,200,400,800"
@@ -1782,9 +1781,9 @@
msgstr ""
"<emphasis role=\"bold\">timeout</emphasis> は再送信タイムアウトを指定します "
"(ミリ秒単位)。 たとえば、 タイムアウトが \"100,200,400,800\" の場合、 送信者"
-"がメッセージを再送するのは初回が 100 ミリ秒間 ACK が受信されていない場合、 2 "
-"回目は 200ミリ秒間まで待機してから再送、 以降、 400ミリ秒、 800ミリ秒と続きま"
-"す。"
+"は最初に 100 ミリ秒間 ACK を受信しないとメッセージを再送し、2 "
+"回目は 200ミリ秒間待ってからメッセージを再送します (3 回目は 400ミリ秒、4 回目は 800ミリ秒と続きま"
+"す)。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:625
@@ -1814,7 +1813,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"
@@ -1822,10 +1821,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
@@ -1888,13 +1888,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
@@ -1940,7 +1938,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"
@@ -1951,9 +1949,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
@@ -1986,7 +1985,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:699
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">print_local_addr</emphasis> specifies whether to "
"dump the node's own address to the output when started."
@@ -2023,6 +2022,8 @@
"together at the same time, only sending out 1 new view / bundle. This is is "
"more efficient than handling each request separately."
msgstr ""
+"<emphasis role=\"bold\">view_bundling</emphasis> は、同時に到着した複数の "
+"JOIN または LEAVE 要求をまとめて同時に処理し、 1 つの新しいビュー/バンドルのみを送出するかどうかを指定します。 これは、各要求を別々に処理するよりも効率的です。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:720
@@ -2032,7 +2033,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:721
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The flow control service tries to adapt the sending data rate and the "
"receiving data among nodes. If a sender node is too fast, it might overwhelm "
@@ -2048,13 +2049,12 @@
"the JGroups <literal>Config</literal> element. Here is an example "
"configuration."
msgstr ""
-"フロー制御サービスはノード内のデータ受信とデータ送信率との適合を試行します。 "
-"送信側ノードが早すぎる場合は、 受信側ノードに負担をかけて再送されなければなら"
-"ないパケットをドロップさせます。 JGroups では、 フロー制御はクレジットベース"
+"フロー制御サービスはノード間のデータ送信率とデータ受信率を変更しようとします。 "
+"送信側ノードが早すぎる場合は、 受信側ノードが対応できないのでパケットが破棄され、パケットを再送しなければならなくなります。JGroups では、 フロー制御はクレジットベース"
"のシステムで実装されます。 送信側と受信側のノードは同じクレジット数 (バイト) "
"を開始時に持っています。 送信側は送信するメッセージのバイト数のクレジットを引"
"きます。 受信側は受信するメッセージのバイトに対するクレジットを累積します。 "
-"送信側のクレジットがしきい値までドロップすると、 受信側は送信側にいくつかクレ"
+"送信側のクレジットがしきい値まで小さくなると、 受信側は送信側にいくつかクレ"
"ジットを送ります。 送信側のクレジットがなくなると、 受信側からクレジットを受"
"け取るまで送信側はブロックします。 フロー制御サービスは JGroups "
"<literal>Config</literal> エレメント配下の <literal>FC</literal> サブエレメン"
@@ -2062,14 +2062,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
@@ -2120,7 +2120,7 @@
"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 秒後にクレジットが受信されないと、 クレジットが現在 0 よりも下の受信側に、 その受信側がクレジットが 0 よりも下のすべてのメンバからクレジットを受信するまで明示的なクレジット要求が送信されます。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:755
@@ -2143,13 +2143,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 呼び出しを使用するアプリケーションは、 呼び出しを行う hread がグループのすべてのメンバからの応答の待機をブロックする同期通信が全体的な呼び出し率を低下させるため、 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
@@ -2166,6 +2166,11 @@
"1M messages. (BTW: this is also the reason why we need NAKACK, although TCP "
"does its own retransmission)."
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 は 100M を受信しますが、 D は "
+"1M メッセージしか受信しない可能性があります (注記: これは TCP "
+"が独自に再送信しても NAKACK が必要な理由ともなります)。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:767
@@ -2178,7 +2183,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 "JGroups は元の送信側 S がダウンし、 ノードが S のメッセージの再送信を求める場合のためにメモリ内にすべてのメッセージをバッファする必要があります。 すべてのメンバは受信したすべてのメッセージをバッファするため、 安定したメッセージ (誰もが見られるメッセージ) を時々消去する必要があります。 これは、 STABLE プロトコルによって行われ、安定性プロトコルラウンドタイムベース (50 秒ごと) またはサイズベース (400K 受信データごと) を実行するよう設定できます。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:770
@@ -2191,6 +2196,8 @@
"in the above case that this is still much faster for A-B and A-C than for A-"
"D."
msgstr ""
+"上記のケースでは、 低速なノード D によってグループが 1M を超えるメッセージを消去することができず、 各メンバが 99M メッセージをバッファします。 ほとんどの場合、 これにより OOM 例外が発生します。 TCP のスライドウィンドウプロトコルではウィンドウがいっぱいである場合書き込みがブロックされますが、上記のケースでは A-"
+"D よりも A-B と A-C の方が高速であると見なすことに注意してください。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:773
@@ -2198,13 +2205,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
@@ -2214,7 +2221,7 @@
"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
@@ -2227,6 +2234,8 @@
"making calls would block waiting for responses from D, thus naturally "
"slowing the overall rate of calls."
msgstr ""
+"このようなアプリケーションの良い例として、 同期グループ "
+"RPC 呼び出しを行うアプリケーションがあります (通常は JGroups RpcDispatcher を使用)。 ここで同期とは、 呼び出しがグループのすべてのメンバからの応答の待機をブロックするようにするスレッドを意味します。 このようなアプリケーションでは、 呼び出しを行う A のスレッドが D からの応答の待機をブロックし、その結果全体の呼び出しのレートが低下します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:786
@@ -2236,7 +2245,7 @@
"application that makes synchronous group RPC calls. If a channel is only "
"used for a cache configured for REPL_SYNC, we recommend you remove FC from "
"its protocol stack."
-msgstr ""
+msgstr "REPL_SYNC に設定された JBoss Cache クラスタは同期グループ RPC 呼び出しを行うアプリケーションの良い例です。 チャネルが REPL_SYNC に設定されたキャッシュに対してのみ使用される場合は、プロトコルスタックから FC を削除することをお勧めします。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:789
@@ -2246,7 +2255,7 @@
"a TCP-based protocol stack is unnecessary. There is no group beyond the "
"single peer-to-peer relationship, and TCP's internal flow control will "
"handle that just fine."
-msgstr ""
+msgstr "また、 当然クラスタが 2 つのノードのみから構成される場合は、 FC を TCP ベースのプロトコルスタックに含めることは必要ありません。 単一のピアツーピア関係を超えるグループは存在せず、 TCP の内部フロー制御はこれを適切に処理します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:792
@@ -2260,12 +2269,14 @@
"engineered buddy replication use case these should be infrequent. But if you "
"remove FC be sure to load test your application.)"
msgstr ""
+"FC が必要ではない別のケースは、 バディレプリケーションと単一バディに対して設定された JBoss "
+"Cache により使用されるチャネルを使用する場合です。 このようなチャネルは多くの点で 2 ノードクラスタのように動作し、 メッセージはもう 1 つのノード (バディ) とのみ交換されます (すべてのメンバに送信されるデータグラビテーションに関する他のメッセージが存在する場合がありますが、 適切に設計されたバディレプリケーションのケースではそのようなことはほとんどありません。 ただし、 FC を削除する場合はアプリケーションの負荷をテストしてください)。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:802
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Fragmentation"
-msgstr "organization"
+msgstr "断片化"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:803
@@ -2275,7 +2286,7 @@
"the receiver's side. It works for both unicast and multicast messages. It is "
"configured in the FRAG2 sub-element under the JGroups Config element. Here "
"is an example configuration."
-msgstr ""
+msgstr "このプロトコルは、特定のサイズよりも大きいメッセージを断片化し、受信者側で非断片化します。 ユニキャストメッセージとマルチキャストメッセージの両方に使用でき、 JGroups Config エレメントの FRAG2 サブエレメントで設定されます。以下に設定例を示します。"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:806
@@ -2285,22 +2296,23 @@
" <FRAG2 frag_size=\"60000\" down_thread=\"false\" up_thread="
"\"false\"/>]]>"
msgstr ""
+"<![CDATA[ \n"
+" <FRAG2 frag_size=\"60000\" down_thread=\"false\" up_thread="
+"\"false\"/>]]>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:808
-#, fuzzy, no-c-format
+#, no-c-format
msgid "The configurable attributes in the FRAG2 element are as follows."
-msgstr "<literal>FC</literal> エレメントで使用できる属性は以下の通りです。"
+msgstr "FRAG2 エレメントで設定できる属性は以下のとおりです。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:813
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in "
"bytes. Messages larger than that are fragmented."
-msgstr ""
-"<emphasis role=\"bold\">max_credits</emphasis> はクレジット (バイト単位) の最"
-"大数を指定します。 この値は JVM ヒープサイズより小さくしてください。"
+msgstr "<emphasis role=\"bold\">frag_size</emphasis> は、フラグの最大サイズ (バイト数単位) を指定します。これよりも大きいメッセージは断片化されます。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:817
@@ -2310,7 +2322,7 @@
"protocol is still needed if FC is used. The reason for this is that if you "
"send a message larger than FC.max_bytes, FC protocol would block. So, "
"frag_size within FRAG2 needs to be set to always be less than FC.max_bytes."
-msgstr ""
+msgstr "TCP プロトコルにより断片化が提供されますが、 FC が使用される場合は JGroups の断片化プロトコルが必要です。 これは、 FC.max_bytes よりも大きいメッセージを送信する場合は、 FC プロトコルがブロックするからです。 したがって、 FRAG2 内の frag_size は常に FC.max_bytes よりも小さく設定する必要があります。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:826
@@ -2335,12 +2347,9 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:831
-#, fuzzy, no-c-format
+#, no-c-format
msgid "<pbcast.STATE_TRANSFER down_thread=\"false\" up_thread=\"false\"/>"
-msgstr ""
-"<pbcast.STATE_TRANSFER \n"
-" down_thread=\"false\"\n"
-" up_thread=\"false\"/>"
+msgstr "<pbcast.STATE_TRANSFER down_thread=\"false\" up_thread=\"false\"/>"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:835
@@ -2371,7 +2380,7 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:840
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<pbcast.STABLE stability_delay=\"1000\"\n"
" desired_avg_gossip=\"5000\" \n"
@@ -2380,8 +2389,8 @@
msgstr ""
"<pbcast.STABLE stability_delay=\"1000\"\n"
" desired_avg_gossip=\"5000\" \n"
-" down_thread=\"false\"\n"
-" max_bytes=\"250000\"/>"
+" down_thread=\"false\" up_thread=\"false\"\n"
+" max_bytes=\"400000\"/>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:842
@@ -2422,7 +2431,7 @@
"<emphasis role=\"bold\">stability_delay</emphasis> specifies delay before we "
"send STABILITY msg (give others a change to send first). If used together "
"with max_bytes, this attribute should be set to a small number."
-msgstr ""
+msgstr "<emphasis role=\"bold\">stability_delay</emphasis> は、STABILITY msg を送信するまでの遅延を指定します (他方に最初に送信する変更を与えます)。 max_bytes とともに使用されている場合は、この属性を小さい数に設定する必要があります。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:859
@@ -2460,14 +2469,15 @@
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:869
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<MERGE2 max_interval=\"10000\"\n"
" min_interval=\"2000\"\n"
" down_thread=\"false\" up_thread=\"false\"/>"
msgstr ""
"<MERGE2 max_interval=\"10000\"\n"
-" min_interval=\"2000\"/>"
+" min_interval=\"2000\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:875
@@ -2512,12 +2522,14 @@
"used with TCP to provide multicast member discovery capabilities, instead of "
"TCPPING to avoid having to specify all the nodes."
msgstr ""
+"クラスタ状態はマージャー内にマージされません。 これは、 アプリケーションによって行う必要があります。 <literal>MERGE2</literal> を "
+"TCPPING とともに使用する場合は、 マージプロセスが適切に実行されるように <literal>initial_hosts</literal> 属性に再びマージできるすべてのノードを含める必要があります。 さもないと、遠ざける機能 (shunning) を無効にしていてもマージプロセスですべてのノードがマージされません。 または、 MPING を使用します。 MPING は一般的にマルチキャストメンバ検出機能を提供するために TCP とともに使用されます (すべてのノードを指定しなくてもすむように TCPPING を使用しません)。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:892
#, no-c-format
msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
+msgstr "特定のインターフェースへの JGroups チャネルのバインド"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:893
@@ -2526,7 +2538,7 @@
"In the Transport Protocols section above, we briefly touched on how the "
"interface to which JGroups will bind sockets is configured. Let's get into "
"this topic in more depth:"
-msgstr ""
+msgstr "上記の「トランスポートプロトコル」セクションでは、 JGroups がソケットをバインドするインターフェースを設定する方法について簡単に説明しました。 ここではこのトピックについて詳しく説明します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:896
@@ -2539,7 +2551,7 @@
"property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) "
"switch, the AS will set <literal>jgroups.bind_addr</literal> to the "
"specified value."
-msgstr ""
+msgstr "最初に、システムプロパティ jgroups.bind_addr (または廃止された初期の名前である <literal>bind.address</literal>) が設定されている場合に XML 設定ファイルの bind_addr エレメントに設定された値が JGroups によって無視されることを理解することが重要です。このシステムプロパティは XML よりも優先されます。 JBoss AS が -b (別名 --host) スイッチを使用して起動されると AS は <literal>jgroups.bind_addr</literal> を指定された値に設定します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:899
@@ -2549,7 +2561,7 @@
"to localhost if -b is not set. The effect of this is that in most cases "
"users are going to be setting -b and thus jgroups.bind_addr is going to be "
"set and any XML setting will be ignored."
-msgstr ""
+msgstr "AS 4.2.0 以降は、 -b が設定されていない場合はセキュリティ上の理由から AS はほとんどのサービスを localhost にバインドします。 この結果、ほとんどの場合、ユーザーは -b を設定し、 jgroups.bind_addr が設定され、 XML 設定が無視されることになります。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:902
@@ -2557,19 +2569,19 @@
msgid ""
"So, what are <emphasis>best practices</emphasis> for managing how JGroups "
"binds to interfaces?"
-msgstr ""
+msgstr "JGroups がインターフェースにバインドする方法を管理する<emphasis>ベストプラクティス</emphasis>は何ですか?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:907
#, no-c-format
msgid "Binding JGroups to the same interface as other services. Simple, just use -b:"
-msgstr ""
+msgstr "JGroups を他のサービスとして同じインターフェースにバインドすることです。 単純に -b を使用します。"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:909
#, no-c-format
msgid "./run.sh -b 192.168.1.100 -c all"
-msgstr ""
+msgstr "./run.sh -b 192.168.1.100 -c all"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:913
@@ -2581,6 +2593,8 @@
"property overrides the -b value. This is a common usage pattern; put client "
"traffic on one network, with intra-cluster traffic on another."
msgstr ""
+"サービス (JBoss Web など) を 1 つのインターフェースにバインドしますが、 JGroups には異なるインターフェースを使用します (<screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>)。 特別に設定されたシステムプロパティは -b 値よりも優先されます。 これは一般的な使用パターンであり、 一方のネットワークにクライアントトラフィックを割り当て、もう一方のネットワークにクラスタ間トラフィックを割り当てます。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:921
@@ -2592,7 +2606,7 @@
"the machine's default interface. See the Transport Protocols section for how "
"to tell JGroups to receive or send on all interfaces, if that is what you "
"really want."
-msgstr ""
+msgstr "サービス (JBoss Web など) をすべてのインターフェースにバインドします。これは、<screen>./run.sh -b 0.0.0.0 -c all</screen> のように指定して行います。ただし、これを行うと JGroups がすべてのインターフェースにバインドしません。 代わりに JGroups はマシンのデフォルトのインターフェースにバインドします。 JGroups がすべてのインターフェースで送受信するよう指示する方法については、 「トランスポートプロトコル」セクションを参照してください。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:929
@@ -2603,18 +2617,21 @@
"bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
"system property overrides the -b value."
msgstr ""
+"すべてのインターフェースにサービス (JBoss Web など) をバインドしますが、 "
+"JGroups インターフェースを指定します (<screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>)。 繰り返しますが、システムプロパティを設定すると、その値は -b 値よりも優先されます。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:937
#, no-c-format
msgid "Using different interfaces for different channels:"
-msgstr ""
+msgstr "異なるチャネルに異なるインターフェースを使用します。"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:939
#, no-c-format
msgid "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
-msgstr ""
+msgstr "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:944
@@ -2625,12 +2642,14 @@
"would need to edit the various XML configuration files to set the "
"<literal>bind_addr</literal> to the desired interfaces."
msgstr ""
+"この設定では、JGroups が <literal>jgroups.bind_addr</"
+"literal> システムプロパティを無視し、代わりに XML で指定された値を使用します。 <literal>bind_addr</literal> を希望のインターフェースに設定するにはさまざまな XML 設定ファイルを編集する必要があります。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:949
#, no-c-format
msgid "Isolating JGroups Channels"
-msgstr ""
+msgstr "JGroups チャネルの分離"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:950
@@ -2641,7 +2660,7 @@
"replication, EJB3 SFSB replication and EJB3 entity replication) along with "
"the general purpose clustering service called HAPartition that underlies "
"most other JBossHA services."
-msgstr ""
+msgstr "JBoss AS 内には、 3 つの異なる JBoss Cache サービス (HttpSession レプリケーション、 EJB3 SFSB レプリケーション、 および EJB3 エンティティレプリケーション) や他のほとんどの JBossHA サービスを基礎となる HAPartition という名前の汎用クラスタリングサービスなど JGroups チャネルを独立して作成する複数のサービスが存在します。 "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:953
@@ -2652,7 +2671,7 @@
"for the same service opened on machines not meant to be part of the group. "
"Nodes improperly communicating with each other is one of the most common "
"issues users have with JBoss AS clustering."
-msgstr ""
+msgstr "これらのチャネルは目的のピアとのみ通信することが重要です (他のサービスで使用されるチャネルや、グループの一部ではないマシンで開かれた同じサービスのチャネルとは通信しません)。 ノードがお互いに適切に通信しないことは、 JBoss AS クラスタリングでユーザーが直面する最も一般的な問題の 1 つです。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:956
@@ -2662,7 +2681,7 @@
"multicast address, and multicast port, so isolating JGroups channels comes "
"down to ensuring different channels use different values for the group name, "
"multicast address and multicast port."
-msgstr ""
+msgstr "JGroups チャネルが通信する相手はそのグループ名、マルチキャストアドレス、およびマルチキャストポートによって定義され、 JGroups チャネルを分離すると、異なるチャネルがグループ名、マルチキャストアドレス、マルチキャストポートに異なる値を使用します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:959
@@ -2672,6 +2691,8 @@
"instances from each other, you MUST change the group name and the multicast "
"port. In other words, each channel must have its own set of values."
msgstr ""
+"AS "
+"インスタンスの同じセット上の異なるサービスの JGroups チャネルをお互いから分離する場合は、グループ名とマルチキャストポートを変更する必要があります。つまり、各チャネルは独自の値セットを持つ必要があります。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:962
@@ -2683,6 +2704,9 @@
"Cache channels. They should use a different group name and multicast port. "
"They can use the same multicast address, although they don't need to."
msgstr ""
+"たとえば、3 つのマシンから構成された本番稼働クラスタがあり、各マシンで HAPartition がデプロイされ、 "
+"Web セッションクラスタリングに JBoss Cache が使用されているとします。 HAPartition チャネルは JBoss "
+"Cache チャネルと通信してはいけないものとし、異なるグループ名とマルチキャストポートを使用する必要があるとします。また、同じマルチキャストアドレスを使用できるが、使用する必要はないものとします。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:965
@@ -2691,7 +2715,7 @@
"To isolate JGroups channels for the same service from other instances of the "
"service on the network, you MUST change ALL three values. Each channel must "
"have its own group name, multicast address, and multicast port."
-msgstr ""
+msgstr "ネットワーク上のサービスの他のインスタンスから同じサービスの JGroups チャネルを分離するには、すべての 3 つの値を変更する必要があります。 各チャネルは独自のグループ名、マルチキャストアドレス、マルチキャストポートを持つ必要があります。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:968
@@ -2702,13 +2726,13 @@
"of 3 machines, which also has an HAPartition deployed. The HAPartition group "
"name, multicast address, and multicast port for the production machines must "
"be different from those used on the QA machines."
-msgstr ""
+msgstr "たとえば、 3 つのマシンから構成された本番クラスタであり、各マシンで HAPartition がデプロイされているとします。また、同じネットワークには 3 つのマシンから構成される QA クラスタがあり、同様に HAPartition がデプロイされているとします。この場合、本番稼働用マシンの HAPartition グループ、マルチキャストアドレス、およびマルチキャストポートは、 QA マシンで使用されているものと異なる必要があります。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:974
#, no-c-format
msgid "Changing the Group Name"
-msgstr ""
+msgstr "グループ名の変更"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:975
@@ -2721,6 +2745,8 @@
"PartitionName attribute. For JBoss Cache services, the name of the attribute "
"is ClusterName."
msgstr ""
+"JGroups チャネルのグループ名はチャネルを開始したサービスによって設定されます。 問題は、 この設定で異なるサービスが異なる属性名を使用することです。 HAPartition と deploy/cluster-service.xml ファイルで設定された関連するサービスの場合、 これは "
+"PartitionName 属性により設定されます。 JBoss Cache サービスの場合、 属性の名前は ClusterName です。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:978
@@ -2734,6 +2760,10 @@
"configuration of the group name in all the standard clustering configuration "
"files. For example,"
msgstr ""
+"JBoss AS 4.0.4 以降、 HAPartition とすべての標準的な JBoss "
+"Cache サービスに対して JBoss の起動時に -g (または –partition) スイッチを使用するだけで一意のグループ名を簡単に作成できるようになりました (<screen>./"
+"run.sh -g QAPartition -b 192.168.1.100 -c all</screen>)。 このスイッチは "
+"jboss.partition.name システムプロパティを設定し、このプロパティはすべての標準的なクラスタリング設定ファイルのグループ名の設定で構成要素として使用されます。たとえば、以下のようになります。"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:982
@@ -2742,12 +2772,14 @@
"<![CDATA[<attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:"
"Cluster}</attribute>]]>"
msgstr ""
+"<![CDATA[<attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:"
+"Cluster}</attribute>]]>"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:988
#, no-c-format
msgid "Changing the multicast address and port"
-msgstr ""
+msgstr "マルチキャストアドレスとポートの変更"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:989
@@ -2760,6 +2792,10 @@
"udpGroup system property, which you can see referenced in all of the "
"standard protocol stack configs in JBoss AS:"
msgstr ""
+"-u (または --udp) コマンドラインスイッチを使用すると、 すべての標準的な AS "
+"サービスによって開かれた JGroups チャネルが使用するマルチキャストアドレスを制御できます。 <screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b "
+"192.168.1.100 -c all]]></screen> このスイッチは jboss.partition."
+"udpGroup システムプロパティを設定し、 このプロパティは JBoss AS のすべての標準的なプロトコルスタック設定で参照できます。"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:995
@@ -2769,6 +2805,9 @@
"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\"\n"
" ....]]>"
msgstr ""
+"<![CDATA[<Config>\n"
+"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\"\n"
+" ....]]>"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:996
@@ -2780,7 +2819,7 @@
"are no command line switches to set these, but the standard configuration "
"files do use system properties to set them. So, they can be configured from "
"the command line by using -D. For example,"
-msgstr ""
+msgstr "残念なことにマルチキャストポートの設定はそれほど単純ではありません。 上述したようにデフォルトでは標準的な JBoss AS のすべての設定には 4 つの異なる JGroups チャネルが存在し、各 チャネルには一意のポートを割り当てる必要があります。 これらを設定するコマンドラインスイッチは存在しませんが、 標準的な設定ファイルではこれらの設定にシステムプロパティを使用します。 したがって、 -D を使用してコマンドラインから設定できます。 以下に例を示します。"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:999
@@ -2793,6 +2832,12 @@
"mcast_port=23456 -Djboss.ejb3entitypartition.mcast_port=34567 -Djboss."
"ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 -c all"
msgstr ""
+"/run.sh -u 230.1.2.3 -g QAPartition\n"
+" -Djboss.messaging.controlchanneludpport_port=21234\n"
+" -Djboss.messaging.datachanneludpport_port=22345\n"
+" -Djboss.hapartition.mcast_port=12345 -Djboss.webpartition."
+"mcast_port=23456 -Djboss.ejb3entitypartition.mcast_port=34567 -Djboss."
+"ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 -c all"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1001
@@ -2800,13 +2845,13 @@
msgid ""
"The ports in the above example are randomly chosen for demonstration "
"purposes only."
-msgstr ""
+msgstr "上記の例のポートは、 デモ目的のためにランダムに選択されています。"
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1006
#, no-c-format
msgid "Why isn't it sufficient to change the group name?"
-msgstr ""
+msgstr "なぜグループ名を変更するだけでは十分ではないのですか?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1007
@@ -2816,13 +2861,13 @@
"port, the lower level JGroups protocols in each channel will see, process "
"and eventually discard messages intended for the other group. This will at a "
"minimum hurt performance and can lead to anomalous behavior."
-msgstr ""
+msgstr "グループ名が異なるチャネルが同じマルチキャストアドレスとポートを共有する場合は、各チャネルの下位のレベルの JGroups プロトコルが他のグループ向けのメッセージを確認および処理し、結果的に破棄します。 これにより少なくともパフォーマンスが低下し、異常な動作が起こることがあります。"
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1011
#, no-c-format
msgid "Why do I need to change the multicast port if I change the address?"
-msgstr ""
+msgstr "アドレスを変更した場合になぜマルチキャストポートを変更しなければならないのですか?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1012
@@ -2835,19 +2880,19 @@
"Linux, where it was most prevalent, as of 4.2 CP06 and 4.3 CP04, but if you "
"have problems when just changing the address, you should change the ports as "
"well."
-msgstr ""
+msgstr "アドレスを変更するだけで十分なはずですが、特定のマルチキャストポートに指定されたパケットが、リッスンしているマルチキャストアドレスに関係なくそのポートのすべてのリスナに送信される複数のオペレーティングシステムで問題が発生します。 この問題は、 最も影響を受けていた Linux 向けのバージョン (4.2 CP06 と 4.3 CP04) で解決されましたが、 アドレスを変更するときに問題が発生した場合はポートも変更する必要があります。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1018
-#, fuzzy, no-c-format
+#, no-c-format
msgid "JGroups Troubleshooting"
-msgstr "トラブルシューティング"
+msgstr "JGroups のトラブルシューティング"
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1019
#, no-c-format
msgid "Nodes do not form a cluster"
-msgstr ""
+msgstr "ノードがクラスタを形成しない"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1021
@@ -2858,6 +2903,8 @@
"McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> "
"directory and start McastReceiverTest, for example:"
msgstr ""
+"使用しているマシンが IP マルチキャストを使用するよう正しく設定されていることを確認します。これを検出するために使用できるテストプログラムには McastReceiverTest と "
+"McastSenderTest の 2 つがあります。 <literal>$JBOSS_HOME/server/all/lib</literal> ディレクトリに移動し、 McastReceiverTest を起動します。 例を以下に示します。"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1023
@@ -2866,12 +2913,14 @@
"java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr "
"224.10.10.10 -port 5555"
msgstr ""
+"java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr "
+"224.10.10.10 -port 5555"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1026
#, no-c-format
msgid "Then in another window start <literal>McastSenderTest</literal>:"
-msgstr ""
+msgstr "次に、別のウィンドウで <literal>McastSenderTest</literal> を起動します。"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1028
@@ -2880,6 +2929,8 @@
"java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr "
"224.10.10.10 -port 5555"
msgstr ""
+"java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr "
+"224.10.10.10 -port 5555"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1031
@@ -2890,6 +2941,9 @@
"address of the NIC to which you want to bind. Use this parameter in both the "
"sender and the receiver."
msgstr ""
+"特定のネットワークインターフェースカード (NIC) にバインドする場合は、 "
+"<literal>-bind_addr 192.168.0.2</literal> を使用します。 ここで、 192.168.0.2 はバインドする NIC の IP "
+"アドレスです。送信側と受信側の両方でこのパラメータを使用します。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1034
@@ -2904,13 +2958,13 @@
"Once you know multicast is working properly on each machine in your cluster, "
"you can repeat the above test to test the network, putting the sender on one "
"machine and the receiver on another."
-msgstr ""
+msgstr "<literal>McastSenderTest</literal> ウィンドウに入力すると、 <literal>McastReceiverTest</literal> ウィンドウに出力が表示されるはずです。 これが不可能な場合は、 送信側で -ttl 32 を使用してください。また失敗した場合は、 IP マルチキャストを正しく設定する方法についてシステム管理者に問い合わせ、 システム管理者に、 選択したインターフェースでマルチキャストが動作するよう確認してもらうか、マシンに複数のインターフェースがある場合は、 正しいインターフェースを教えてもらいます。 マルチキャストがクラスタ内の各マシンで正しく動作している場合は、 送信側をあるマシン、受信側を別のマシンに割り当てることによって上記のテストを繰り返してネットワークをテストできます。"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1041
#, no-c-format
msgid "Causes of missing heartbeats in FD"
-msgstr ""
+msgstr "FD でハートビートが不明な原因"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1042
@@ -2920,7 +2974,7 @@
"received for some time T (defined by timeout and max_tries). This can have "
"multiple reasons, e.g. in a cluster of A,B,C,D; C can be suspected if (note "
"that A pings B, B pings C, C pings D and D pings A):"
-msgstr ""
+msgstr "ハートビート ACK を時間 T (タイムアウトと max_tries によって定義される) の間受け取らないため、メンバが FD によって疑われることがあります。. これには複数の理由が考えられます。 たとえば、 A、 B、 C、 D のクラスタでは以下の場合に C が疑われることがあります (A は B、 B は C、 C は D、 D は A に対して ping を実行します)。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1048
@@ -2928,19 +2982,19 @@
msgid ""
"B or C are running at 100% CPU for more than T seconds. So even if C sends a "
"heartbeat ack to B, B may not be able to process it because it is at 100%"
-msgstr ""
+msgstr "B または C の CPU 稼働率が T 秒以上 100% である場合。したがって、 C がハートビート ACK を B に送信しても、 B は CPU 稼働率が 100% であるためそれを処理できません。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1053
#, no-c-format
msgid "B or C are garbage collecting, same as above."
-msgstr ""
+msgstr "B または C がガーベッジコレクションを実行している場合 (上記と同様)。"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1058
#, no-c-format
msgid "A combination of the 2 cases above"
-msgstr ""
+msgstr "上記の 2 つのケースの組み合わせ"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1063
@@ -2949,7 +3003,7 @@
"The network loses packets. This usually happens when there is a lot of "
"traffic on the network, and the switch starts dropping packets (usually "
"broadcasts first, then IP multicasts, TCP packets last)."
-msgstr ""
+msgstr "ネットワークでパケットが失われる場合。 これは通常、ネットワークに大量のトラフィックが存在し、スイッチがパケットの破棄を開始したときに発生します (通常は最初にブロードキャスト、次に IP マルチキャスト、最後に TCP パケットが失われます)、"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1068
@@ -2960,4 +3014,6 @@
"will not process any other messages, including heartbeats, and therefore B "
"will not receive the heartbeat ack and will suspect C."
msgstr ""
+"B または C がコールバックを処理している場合。 C がチャネルを介してリモートメソッド呼び出しを受信し、その処理に T+1 秒かかるとします。 この時間の間、 C はハートビートを含む他のすべてのメッセージを処理しません。 したがって B "
+"はハートビート ACK を受信せず、 C を疑うことになります。"
More information about the jboss-cvs-commits
mailing list