[jboss-cvs] JBossAS SVN: r85145 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Mar 3 00:39:40 EST 2009
Author: hpeters
Date: 2009-03-03 00:39:40 -0500 (Tue, 03 Mar 2009)
New Revision: 85145
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
translation update in progress
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po 2009-03-03 05:31:55 UTC (rev 85144)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po 2009-03-03 05:39:40 UTC (rev 85145)
@@ -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-25 09:40+1000\n"
+"PO-Revision-Date: 2009-03-03 15:12+1000\n"
"Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
@@ -21,7 +21,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:5
#, no-c-format
msgid "JBossCache and JGroups Services"
-msgstr "Das JBossCache und JGroups-Dienste"
+msgstr "Das JBossCache und JGroups Dienste"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:6
@@ -258,13 +258,13 @@
"is what defines the characteristics of the overall Channel. In the next "
"several sections, we will dig into the commonly used protocols and their "
"options and explain exactly what they mean."
-msgstr "Alle JGroups Konfigurationsdaten sind im <Config>-Element unter dem JGroups config-MBean-Attribut enthalten. Diese Informationen. Diese Informationen werden zur Konfiguration eines JGroups Channels verwendet; der Channel hat konzeptionell Ähnlichkeit mit einem Socket, und verwaltet die Kommunikation zwischen Peers in einem Cluster. Jedes Element innerhalb des <Config>-Elements definiert ein bestimmtes JGroups Protokoll; jedes dieser Protokolle erfüllt eine Funktion, und die Kombination dieser Funktionen bildet die Charakteristiken des gesamten Channels. In den nächsten Abschnitten gehen wir näher auf die gebräuchlichen Protokolle und ihre Optionen ein und erläutern deren Bedeutung."
+msgstr "Alle JGroups-Konfigurationsdaten sind im <Config>-Element unter dem JGroups config-MBean-Attribut enthalten. Diese Informationen werden zur Konfiguration eines JGroups Channels verwendet; der Channel hat konzeptionell Ähnlichkeit mit einem Socket, und verwaltet die Kommunikation zwischen Peers in einem Cluster. Jedes Element innerhalb des <Config>-Elements definiert ein bestimmtes JGroups-Protokoll; jedes dieser Protokolle erfüllt eine Funktion, und die Kombination dieser Funktionen bildet die Charakteristiken des gesamten Channels. In den nächsten Abschnitten gehen wir näher auf die gängigen Protokolle und ihre Optionen ein und erläutern deren Bedeutung."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:38
#, no-c-format
msgid "Common Configuration Properties"
-msgstr "Gebräuchliche Konfigurationseigenschaften"
+msgstr "Gängige Konfigurationseigenschaften"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:39
@@ -272,7 +272,7 @@
msgid ""
"The following common properties are exposed by all of the JGroups protocols "
"discussed below:"
-msgstr "Die folgenden allgemein gebräuchlichen Eigenschaften werden von allen unten behandelten JGroups Protokollen offengelegt:"
+msgstr "Die folgenden gängigen Eigenschaften werden von allen unten behandelten JGroups-Protokollen offengelegt:"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:43
@@ -288,7 +288,7 @@
"is responsible for reading messages off the queue, doing whatever protocol-"
"specific processing is required, and passing the message on to the next "
"protocol in the stack."
-msgstr "<literal>down_thread</literal> bestimmt, ob das Protokoll eine interne und einen Queue-Verarbeitungs-Thread (den sog. \"down_thread\") für Nachrichten erstellen soll, die von höhergelegenen Schichten übermittelt werden. Bei der höhergelegenen Schicht kann es sich um ein Protokoll handeln, dass höher im Stapel liegt, oder um die Anwendung selbst, falls das Protokoll bereits das oberste im Stapel ist. Fall auf \"true\" (Standard) gesetzt, wenn eine Nachricht von einer höhergelegenen Schicht übermittelt wird, dann platziert der aufrufende Thread die Nachricht in die Queue des Protokolls und kehrt danach sofort zurück. Der \"down_thread\" des Protokolls ist dafür verantwortlich, Nachrichten aus der Queue auszulesen, die notwendige protokollspezifische Verarbeitung auszuführen, und die Nachricht anschließend zum nächsten Protokoll im Stapel weiterzuleiten."
+msgstr "<literal>down_thread</literal> bestimmt, ob das Protokoll eine interne Warteschlange (\"Queue\") und einen Warteschlangenverarbeitungs-Thread (den sog. \"down_thread\") für Nachrichten erstellen soll, die von höhergelegenen Schichten übermittelt werden. Bei der höhergelegenen Schicht kann es sich um ein Protokoll handeln, dass höher im Stapel liegt, oder um die Anwendung selbst, falls das Protokoll bereits das oberste im Stapel ist. Falls auf \"true\" (Standard) gesetzt, dann platziert der aufrufende Thread die Nachricht, die von einer höheren Schicht übermittelt wird, in die Warteschlange des Protokolls und antwortet dann sofort. Der \"down_thread\" des Protokolls ist dafür verantwortlich, Nachrichten aus der Warteschlange auszulesen, die notwendige protokollspezifische Verarbeitung auszuführen, und die Nachricht anschließend dem nächsten Protokoll im Stapel zu übergeben."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:47
@@ -297,7 +297,7 @@
"<literal>up_thread</literal> is conceptually similar to down_thread, but "
"here the queue and thread are for messages received from lower layers in the "
"protocol stack."
-msgstr "<literal>up_thread</literal> hat konzeptionell Ähnlichkeit mit down_thread, allerdings ist hier die Queue und der Thread für Nachrichten bestimmt, die von tiefergelegenen Schichten im Protokollstapel empfangen werden."
+msgstr "<literal>up_thread</literal> hat konzeptionell Ähnlichkeit mit down_thread, allerdings sind hier die Warteschlange und der Thread für Nachrichten bestimmt, die von tieferen Schichten im Protokollstapel empfangen werden."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:51
@@ -354,9 +354,9 @@
"element. Here is an example."
msgstr ""
"UDP ist das bevorzugte Protokoll für JGroups. UDP verwendet Multicast oder "
-"mehrere Unicasts um Nachrichten zu verschicken oder zu empfangen. Falls Sie "
+"mehrere Unicasts, um Nachrichten zu verschicken oder zu empfangen. Falls Sie "
"UDP als das Transportprotokoll Ihres Cluster-Dienstes wählen, müssen Sie es "
-"im <literal>UDP</literal> Unterelement im JGroups <literal>Config</literal>-"
+"im <literal>UDP</literal>-Unterelement im JGroups <literal>Config</literal>-"
"Element konfigurieren. Nachfolgend sehen Sie ein Beispiel."
#. Tag: programlisting
@@ -404,7 +404,7 @@
#, no-c-format
msgid "The available attributes in the above JGroups configuration are listed below."
msgstr ""
-"Die verfügbaren Attribute in der JGroups Konfiguration oben sind nachfolgend "
+"Die verfügbaren Attribute in der JGroups-Konfiguration oben sind nachfolgend "
"aufgeführt."
#. Tag: para
@@ -424,7 +424,7 @@
"<emphasis role=\"bold\">mcast_addr</emphasis> specifies the multicast "
"address (class D) for joining a group (i.e., the cluster). If omitted, the "
"default is <literal>228.8.8.8 </literal>."
-msgstr "<emphasis role=\"bold\">mcast_addr</emphasis> bestimmt die Multicast-Adresse (Klasse D) zum Anschluss an eine Gruppe (d. h. den Cluster). Falls weggelassen, so lautet der Standard <literal>228.8.8.8</literal>."
+msgstr "<emphasis role=\"bold\">mcast_addr</emphasis> bestimmt die Multicast-Adresse (Klasse D) zum Anschluss an eine Gruppe (d. h. den Cluster). Falls sie weggelassen wird, so lautet der Standard <literal>228.8.8.8</literal>."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:88
@@ -434,7 +434,7 @@
"number. If omitted, the default is <literal>45566</literal>."
msgstr ""
"<emphasis role=\"bold\">mcast_port</emphasis> bestimmt die Nummer des "
-"Multicast-Ports. Falls weggelassen, so lautet der Standard <literal>45566</literal>."
+"Multicast-Ports. Falls sie weggelassen wird, so lautet der Standard <literal>45566</literal>."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:92
@@ -448,8 +448,8 @@
"setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr "
"system property is set."
msgstr ""
-"<emphasis role=\"bold\">bind_addr</emphasis> legt die Schnittstelle fest, auf dem Multicasts empfangen und verschickt werden (verwendet die <literal>-Djgroups.bind_address</literal> Systemeigenschaft, falls vorhanden). Falls Sie ein "
-"Multihome-Gerät besitzen, stellen Sie das <literal>bind_addr</literal>-Attribut oder Systemeigenschaft auf die entsprechende NIC IP-Adresse ein. Standardmäßig hat die Einstellung der Systemeigenschaft Priorität über das XML-Attribut, es sei denn, die -Djgroups.ignore.bind_addr-Systemeigenschaft ist gesetzt."
+"<emphasis role=\"bold\">bind_addr</emphasis> legt die Schnittstelle fest, auf dem Multicasts empfangen und verschickt werden (verwendet die <literal>-Djgroups.bind_address</literal>-Systemeigenschaft, falls vorhanden). Falls Sie ein "
+"Multihome-Gerät besitzen, stellen Sie das <literal>bind_addr</literal>-Attribut oder die Systemeigenschaft auf die entsprechende NIC IP-Adresse ein. Standardmäßig hat die Einstellung der Systemeigenschaft Vorrang vor dem XML-Attribut, es sei denn, die -Djgroups.ignore.bind_addr-Systemeigenschaft ist gesetzt."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:95
@@ -471,7 +471,7 @@
"<emphasis role=\"bold\">send_on_all_interfaces</emphasis> specifies whether "
"this node send UDP packets via all the NICs if you have a multi NIC machine. "
"This means that the same multicast message is sent N times, so use with care."
-msgstr "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> legt fest, ob dieser Node UDP-Pakete via allen NICs versendet, wenn Sie eine Multi-NIC-Maschine besitzen. Dies bedeutet, dass dieselbe Multicast-Nachricht n-mal verschickt wird, lassen Sie also Vorsicht walten."
+msgstr "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> legt fest, ob dieser Node UDP-Pakete via allen NICs versendet, wenn Sie eine Multi-NIC-Maschine besitzen. Dies bedeutet, dass dieselbe Multicast-Nachricht n-mal verschickt wird, verwenden Sie dies also mit Vorsicht."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:105
@@ -483,7 +483,7 @@
"addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</"
"literal>\"."
msgstr ""
-"<emphasis role=\"bold\">receive_interfaces</emphasis> legt eine Liste von Schnittstellen fest, auf denen Multicasts empfangen werden. Der Multicast-Empfangs-Socket wird auf all diesen Schnittstellen lauschen. Es handelt sich hierbei um eine kommagetrennt Liste mit IP-Adressen oder Schnittstellennamen. Z. B. \"<literal>192.168.5.1,eth1,127.0.0.1</"
+"<emphasis role=\"bold\">receive_interfaces</emphasis> legt eine Liste von Schnittstellen fest, auf denen Multicasts empfangen werden. Der Multicast-Empfangs-Socket wird auf all diesen Schnittstellen lauschen. Es handelt sich hierbei um eine kommagetrennt Liste mit IP-Adressen oder Schnittstellennamen, z. B. \"<literal>192.168.5.1,eth1,127.0.0.1</"
"literal>\"."
#. Tag: para
@@ -495,7 +495,7 @@
"but is actually something of a misnomer, since the value here refers to how "
"many network hops a packet will be allowed to travel before networking "
"equipment will drop it."
-msgstr "<emphasis role=\"bold\">ip_ttl</emphasis> legt die Lebenszeit (\"time-to-live\", oder TTL) für IP-Multicast-Pakete fest. TTL ist der gebräuchliche Begriff in Multicast-Networking, obwohl dies tatsächlich eine irreführende Bezeichnung ist. Denn der Wert hier bezieht sich auf die Anzahl der Netzwerksprünge, die ein Paket weitergegeben werden darf, bevor das Netzwerkgeräte es verwerfen."
+msgstr "<emphasis role=\"bold\">ip_ttl</emphasis> legt die Lebenszeit (\"time-to-live\", oder TTL) für IP-Multicast-Pakete fest. TTL ist die gängige Bezeichnung in Multicast-Networking, obwohl dies tatsächlich ein irreführender Begriff ist. Denn der Wert hier bezieht sich auf die Anzahl der Router (\"Network Hops\"), über die ein Paket weiterreicht werden darf, bevor die Netzwerkgeräte es verwerfen."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:115
@@ -507,7 +507,9 @@
"handler is a separate thread taking care of de-serialization, receiver thread"
"(s) simply put packet in queue and return immediately. Setting this to true "
"adds one more thread. The default is <literal>true</literal>."
-msgstr "<emphasis role=\"bold\">use_incoming_packet_handler</emphasis> legt fest, ob ein separater Thread verwendet werden soll zur Verarbeitung von eingehenden Nachrichten. Manchmal können Receiver überladen sein (sie müssen De-Serialisierung usw. erledigen). Der Paket-Handler ist ein separater Thread, der die De-Serialisierung übernimmt, somit muss der Empfänger-Thread nur noch das Paket in die Queue platzieren und kann sofort zurückkehren. Wird dies auf \"true\" gestellt, wird ein weiterer Thread hinzugefügt. Der Standardwert lautet <literal>true</literal>."
+msgstr ""
+"<emphasis role=\"bold\">use_incoming_packet_handler</emphasis> legt fest, ob "
+"ein separater Thread bei der Bearbeitung eingehender Nachrichten verwendet wird. Mitunter können Empfänger überlastet sein (sie müssen Deserialisierung usw. erledigen). Der Paket-Handler ist ein separater Thread, der die Deserialisierung erledigt, somit muss der Empfänger-Thread nur noch das Paket in die Warteschlange platzieren und kann sofort antworten. Die Einstellung \"true\" fügt einen weiteren Thread hinzu. Der Standardwert lautet <literal>true</literal>."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:118
@@ -531,7 +533,7 @@
"elapsed, whichever occurs first. Then bundle queued messages into a large "
"message and send it. The messages are unbundled at the receiver. The default "
"is <literal>false</literal>."
-msgstr "<emphasis role=\"bold\">enable_bundling</emphasis> legt fest, ob das \"Bundling\" (Bündelung) von Nachrichten aktiviert ist. Falls die Einstellung hier <literal>true</literal> lautet, erstellt der Node eine Warteschlange der ausgehenden Nachrichten bis diese <literal>max_bundle_size</literal>-Bytes oder <literal>max_bundle_time</literal>-Millisekunden erreicht haben, je nachdem welcher Wert zuerst erreicht wird. Die in der Warteschlange befindlichen Nachrichten werden dann zu einer großen Nachricht gebündelt und verschickt. Diese wird dann vom Receiver entbündelt. Der voreingestellte Wert lautet <literal>false</literal>."
+msgstr "<emphasis role=\"bold\">enable_bundling</emphasis> legt fest, ob das \"Bundling\" (Bündelung) von Nachrichten aktiviert ist. Falls die Einstellung hier <literal>true</literal> lautet, erstellt der Node eine Warteschlange der ausgehenden Nachrichten, bis diese <literal>max_bundle_size</literal>-Bytes oder <literal>max_bundle_time</literal>-Millisekunden erreicht haben, je nachdem welcher Wert zuerst erreicht wird. Die in der Warteschlange befindlichen Nachrichten werden dann zu einer großen Nachricht gebündelt und verschickt. Diese wird dann vom Empfänger entbündelt. Der voreingestellte Wert lautet <literal>false</literal>."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:129
@@ -573,7 +575,7 @@
"<emphasis role=\"bold\">mcast_send_buf_size, mcast_recv_buf_size, "
"ucast_send_buf_size, ucast_recv_buf_size</emphasis> definiert die "
"Puffergrößen von \"receive\" und \"send\" (empfangen und senden). Es "
-"empfiehlt sich, einen großen Puffer (Zwischenspeicher) für den Receiver zu "
+"empfiehlt sich, einen großen Puffer (Zwischenspeicher) für den Empfänger zu "
"wählen, damit Pakete nicht aufgrund eines Pufferüberlaufs verloren gehen."
#. Tag: para
@@ -666,9 +668,7 @@
"pick a port. Please, bear in mind that setting it to 0 will work only if we "
"use MPING or TCPGOSSIP as discovery protocol because <literal>TCCPING</"
"literal> requires listing the nodes and their corresponding ports."
-msgstr ""
-"<emphasis role=\"bold\">start_port, end_port</emphasis> definiert den Bereich von TCP-Ports, mit welchen sich der Server verbinden soll. Der Server-Socket wird mit dem ersten verfügbaren Port ab <literal>start_port</literal> verbunden. Kann vor Erreichen von <literal>end_port</literal> kein verfügbarer Port gefunden werden (z. B. aufgrund einer Firewall), so wirft der Server eine Ausnahme. Wird <literal>end_port</literal> oder <literal>end_port < start_port</literal> nicht festgelegt, gibt es keine obere Grenze des Port-Bereichs. Bei <literal>start_port == end_port</literal> zwingen wir JGroups, den angegebenen Port zu verwenden (der Start schlägt fehl, falls dieser Port nicht verfügbar ist). Der voreingestellte Wert lautet 7800. Falls 0 eingestellt wird, wählt das Betriebssystem einen Port aus. Beachten Sie bitte, dass eine Einstellung auf 0 nur dann funktionieren kann, wenn MPING oder TCPGOSSIP als Discovery-Protokolle verwendet werden, denn <literal>TCCPING</"
-"literal> erfordert das Lauschen auf die Nodes und deren zugehörige Ports."
+msgstr "<emphasis role=\"bold\">start_port, end_port</emphasis> definiert den Bereich von TCP-Ports, an denen sich der Server verbinden soll. Der Server-Socket bindet an den ersten verfügbaren Port ab <literal>start_port</literal>. Kann vor Erreichen von <literal>end_port</literal> kein verfügbarer Port gefunden werden (z. B. aufgrund einer Firewall), so wirft der Server eine Ausnahme. Wird <literal>end_port</literal> oder <literal>end_port < start_port</literal> nicht festgelegt, existiert keine obere Grenze des Port-Bereichs. Bei <literal>start_port == end_port</literal> zwingen wir JGroups, den angegebenen Port zu verwenden (falls dieser Port nicht verfügbar ist, schlägt der Start fehl). Der voreingestellte Wert lautet 7800. Falls 0 eingestellt wird, wählt das Betriebssystem einen Port aus. Beachten Sie bitte, dass eine Einstellung auf 0 nur dann funktionieren kann, wenn MPING oder TCPGOSSIP als Discovery-Protokolle verwendet werden, denn <literal>TCCPING</litera!
l> erfordert eine Auflistung der Nodes und ihrer zugehörigen Ports."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:182
@@ -688,7 +688,7 @@
"receive and send buffer sizes. It is good to have a large receiver buffer "
"size, so packets are less likely to get dropped due to buffer overflow."
msgstr ""
-"<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> definiert die Puffergrößen von \"receive\" und \"send\" (empfangen und senden). Es empfiehlt sich einen großen Puffer (Zwischenspeicher) für den Receiver zu "
+"<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> definiert die Puffergrößen von \"receive\" und \"send\" (empfangen und senden). Es empfiehlt sich einen großen Puffer (Zwischenspeicher) für den Empfänger zu "
"wählen, damit Pakete nicht aufgrund eines Pufferüberlaufs verloren gehen."
#. Tag: para
@@ -708,7 +708,7 @@
"milliseconds) to run the reaper. If both values are 0, no reaping will be "
"done. If either value is > 0, reaping will be enabled. By default, "
"reaper_interval is 0, which means no reaper."
-msgstr "<emphasis role=\"bold\">reaper_interval</emphasis> bestimmt den Intervall (in Millisekunden), in dem der Reaper ausgeführt wird. Wenn beide Werte 0 lauten, findet kein Reaping statt. Wenn einer der beiden Werte > 0 ist, so ist das Reaping aktiviert. Der voreingestellte Wert für reaper_interval lautet 0, also kein Reaper."
+msgstr "<emphasis role=\"bold\">reaper_interval</emphasis> bestimmt den Intervall (in Millisekunden), in dem der Reaper ausgeführt wird. Wenn beide Werte 0 lauten, findet kein Reaping statt. Wenn einer der beiden Werte > 0 ist, so ist das Reaping aktiviert. Der voreingestellte Wert für reaper_interval lautet 0, d. h. es findet kein Reaping statt."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:200
@@ -727,7 +727,7 @@
"<emphasis role=\"bold\">use_send_queues</emphasis> specifies whether to use "
"separate send queues for each connection. This prevents blocking on write if "
"the peer hangs. The default is true."
-msgstr "<emphasis role=\"bold\">use_send_queues</emphasis> legt fest, ob für jede Verbindung separate Sende-Queues verwendet werden sollen. Dies verhindet das Blockieren beim Schreiben, wenn der Peer hängenbleibt. Der Standard lautet \"true\"."
+msgstr "<emphasis role=\"bold\">use_send_queues</emphasis> legt fest, ob für jede Verbindung separate Sendewarteschlangen verwendet werden sollen. Dies verhindet das Blockieren beim Schreiben, wenn der Peer hängenbleibt. Der Standard lautet \"true\"."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:206
@@ -745,16 +745,19 @@
"node inside the firewall, but only on its external address. Without setting "
"the external_addr, the node behind the firewall will broadcast its private "
"address to the other nodes which will not be able to route to it."
-msgstr "<emphasis role=\"bold\">external_addr</emphasis> legt die externe IP-Adresse fest, die an andere Gruppenmitglieder übertragen wird (falls sie sich von der lokalen Adresse unterscheidet). Dies ist hilfreich, wenn Sie NAT (Network Address Translation) verwenden müssen, z. B. einen Node auf einem privaten Netzwerk, hinter einer Firewall, Sie jedoch nur via einer extern sichtbaren Adresse an ihn weiterleiten können, welche sich unterscheidet von der lokalen Adresse, mit der er verbunden ist. Aus diesem Grund kann der Node so konfiguriert werden, dass er seine externe Adresse überträgt, aber dennoch mit der lokalen Adresse verbunden sein kann. Dadurch wird die Nutzung des TUNNEL-Protokolls vermieden (und damit die Notwendigkeit für einen zentralen Gossip-Router), denn Nodes außerhalb der Firewall können weiterhin zu den Nodes innerhalb der Firewall umleiten, aber nur durch seine externe Adresse. Wird external_addr nicht eingestellt, so wird der Node hinter der Fi!
rewall seine private Adresse an andere Nodes übertragen, die infolgedessen nicht dahin weiterleiten können."
+msgstr "<emphasis role=\"bold\">external_addr</emphasis> legt eine externe IP-Adresse fest, die an andere Gruppenmitglieder übertragen wird (falls sie sich von der lokalen Adresse unterscheidet). Dies ist hilfreich, wenn Sie NAT (Network Address Translation) verwenden müssen, z. B. einen Node auf einem privaten Netzwerk, hinter einer Firewall, Sie jedoch nur via einer extern sichtbaren Adresse an ihn weiterleiten können, welche sich unterscheidet von der lokalen Adresse, an die er gebunden ist. Aus diesem Grund kann der Node so konfiguriert werden, dass er seine externe Adresse überträgt, er aber dennoch mit der lokalen Adresse verbunden sein kann. Dies vermeidet, dass das TUNNEL-Protokoll eingesetzt werden muss (und vermeidet damit auch die Notwendigkeit für einen zentralen Gossip-Router), denn Nodes außerhalb der Firewall können weiterhin zu den Nodes innerhalb der Firewall umleiten, aber nur via seiner externen Adresse. Wird external_addr nicht eingestellt, so wi!
rd der Node hinter der Firewall seine private Adresse an andere Nodes übertragen, die infolgedessen nicht dahin weiterleiten können."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:209
#, no-c-format
+#, fuzzy
msgid ""
"<emphasis role=\"bold\">skip_suspected_members</emphasis> specifies whether "
"unicast messages should not be sent to suspected members. The default is "
"true."
-msgstr "<emphasis role=\"bold\">skip_suspected_members</emphasis> bestimmt, ob Unicast-Nachrichten nicht an vermutete Mitglieder gesendet werden sollen. Die Standardeinstellung lautet <literal>true</literal>."
+msgstr ""
+"<emphasis role=\"bold\">skip_suspected_members</emphasis> bestimmt, ob Unicast-Nachrichten nicht an verdächtigte Mitglieder gesendet werden sollen. Die Standardeinstellung lautet <literal>true</literal>. "
+"(suspected = verdächtigt, as in a node that is suspected to have failed, being unresponsive etc?)"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:212
@@ -767,7 +770,7 @@
"(by setting <literal>enable_bundling</literal> to false). Nagling is "
"disabled by setting <literal>tcp_nodelay</literal> to true. The default is "
"false."
-msgstr "<emphasis role=\"bold\">tcp_nodelay</emphasis> spezifiziert TCP_NODELAY. TCP wendet standardmäßig den \"Nagle\"-Algorithmus auf Nachrichten an, das heißt, dass kleinere Nachrichten zu größeren gebündelt werden. Falls synchrone Cluster-Methodenaufrufe ausgeführt werden sollen, muss der Nagle-Algorithmus wie auch die Nachrichtenbündelung (durch Setzen von <literal>enable_bundling</literal> auf \"false\") deaktiviert werden. Der Nagle-Algorithmus wird deaktiviert, indem <literal>tcp_nodelay</literal> auf \"true\" gesetzt wird. Die Standardeinstellung lautet hier \"false\"."
+msgstr "<emphasis role=\"bold\">tcp_nodelay</emphasis> spezifiziert TCP_NODELAY. TCP wendet standardmäßig den \"Nagle\"-Algorithmus auf Nachrichten an, das heißt, dass kleinere Nachrichten zu größeren gebündelt werden. Falls synchrone Cluster-Methodenaufrufe erfolgen sollen, muss der Nagle-Algorithmus wie auch die Nachrichtenbündelung (durch Setzen von <literal>enable_bundling</literal> auf \"false\") deaktiviert werden. Der Nagle-Algorithmus wird deaktiviert, indem <literal>tcp_nodelay</literal> auf \"true\" gesetzt wird. Die voreingestellte Wert lautet hier \"false\"."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:220
@@ -799,9 +802,7 @@
"Nodes hinter Firewalls verwendet werden. Ein Node kann eine TCP-Verbindung "
"zum GossipRouter durch die Firewall herstellen (Sie können Port 80 "
"verwenden). Dieselbe Verbindung wird vom Router verwendet, um Nachrichten "
-"an Nodes hinter der Firewall zu verschicken. Die TUNNEL-Konfiguration ist im "
-"<literal>TUNNEL</literal>-Element im JGroups <literal>Config</literal>-"
-"Element definiert. Nachfolgend sehen Sie ein Beispiel:"
+"an Nodes hinter der Firewall zu verschicken, denn die meisten Firewalls erlauben es außerhalb liegenden Hosts nicht, eine TCP-Verbindung zu einem Host innerhalb der Firewall zu initiieren. Die TUNNEL-Konfiguration ist im TUNNEL-Element im JGroups Config-Element definiert. Nachfolgend sehen Sie ein Beispiel:"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:226
@@ -874,7 +875,7 @@
"When a new node joins the cluster later, it is only discovered after the "
"group membership protocol (GMS, see <xref linkend=\"jbosscache-jgroups-other-"
"gms\"/>) admits it into the group."
-msgstr "Der Cluster muss zu jedem beliebigen Zeitpunkt eine Liste der aktuellen Mitgliedernodes führen, damit Lastverteiler und Client-Interzeptor wissen, wie Anfragen weitergeleitet werden sollen. Die Discovery-Protokolle dienen dazu, aktive Nodes im Cluster aufzuspüren, sowie das älteste Mitglied im Cluster zu identifizieren – den Koordinator. Alle vorhandenen Nodes werden erkannt, wenn der Cluster startet. Kommt später ein neuer Node hinzu, so wird er erst aufgespürt, nachdem das Group-Membership-Protocol (GMS, siehe <xref linkend=\"jbosscache-jgroups-other-gms\"/>) ihn der Gruppe zuführt."
+msgstr "Der Cluster muss zu jedem beliebigen Zeitpunkt eine Liste der aktuellen Mitglieds-Nodes führen, damit Lastverteiler und Client-Interzeptor wissen, wie Anfragen weitergeleitet werden sollen. Die Discovery-Protokolle dienen dazu, aktive Nodes im Cluster aufzuspüren, sowie das älteste Mitglied im Cluster zu identifizieren – den Koordinator. Alle vorhandenen Nodes werden erkannt, wenn der Cluster startet. Kommt später ein neuer Node hinzu, so wird er erst aufgespürt, nachdem das Group-Membership-Protocol (GMS, siehe <xref linkend=\"jbosscache-jgroups-other-gms\"/>) ihn der Gruppe zuführt."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:256
@@ -884,7 +885,7 @@
"choose to use different discovery protocols based on your transport "
"protocol. These are also configured as sub-elements in the JGroups MBean "
"<literal>Config</literal> element."
-msgstr "Da die Discovery-Protokolle über den Transportprotokollen angesiedelt sind, können Sie je nach Ihrem eigenen Transportprotokoll unterschiedliche Discovery-Protokolle verwenden. Diese sind auch als Unterelemente im JGroups MBean <literal>Config</literal>-Element konfiguriert."
+msgstr "Da die Discovery-Protokolle über den Transportprotokollen angesiedelt sind, können Sie je nach Ihrem eigenen Transportprotokoll unterschiedliche Discovery-Protokolle verwenden. Diese sind auch als Unterelemente im JGroups-MBean <literal>Config</literal>-Element konfiguriert."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:262
@@ -904,7 +905,7 @@
"joiner determines the coordinator from the responses, and sends a JOIN "
"request to it (handled by). If nobody responds, we assume we are the first "
"member of a group."
-msgstr "Das Discovery-Protokoll PING funktioniert, indem es entweder multiple PING-Anfragen an eine IP-Multicast-Adresse überträgt (Multicasting), oder indem es sich mit einem Gossip-Router verbindet. Folglich ist PING normalerweise über den UDP- oder TUNNEL-Transportprotokolls angesiedelt. Jeder Node antwortet mit einem Paket {C, A}, wobei C = die Adresse des Koordinators und A = seine eigene Adresse ist. Nach Erhalt einer Antwort durch Timeout Milliseconds oder num_initial_members, bestimmt der Neuzugang mithilfe der Antworten den Koordinator und sendet ihm eine JOIN-Anfrage. Falls niemand antwortet, nehmen wir an, dass wir das erste Mitglied einer Gruppe sind."
+msgstr "PING ist ein Discovery-Protokoll und funktioniert entweder durch das Übertragen von multiplen PING-Anfragen an eine IP-Multicast-Adresse (Multicasting), oder durch Verbinden mit einem Gossip-Router. Folglich ist PING normalerweise über den UDP- oder TUNNEL-Transportprotokolls angesiedelt. Jeder Node antwortet mit einem Paket {C, A}, wobei C = die Adresse des Koordinators und A = seine eigene Adresse ist. Nach Erhalt einer Antwort durch Timeout Milliseconds oder num_initial_members bestimmt der neu eintretende Node mithilfe der Antworten den Koordinator und sendet ihm eine JOIN-Anfrage. Falls niemand antwortet, nehmen wir an, dass wir das erste Mitglied einer Gruppe sind."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:266
@@ -1175,6 +1176,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:370
#, no-c-format
+#, fuzzy
msgid ""
"<emphasis role=\"bold\">port_range</emphasis> specifies the number of "
"consecutive ports to be probed when getting the initial membership, starting "
@@ -1183,7 +1185,9 @@
"connect to hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, "
"hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options "
"allows for multiple nodes on the same host to be pinged."
-msgstr "<emphasis role=\"bold\">port_range</emphasis> bestimmt die Anzahl aufeinanderfolgender Ports, die beim Erhalt der ersten Mitgliedschaft geprüft werden, beginnend mit dem im initial_hosts-Parameter spezifizierten Port. Nehmen wir die obigen Werte für port_range und initial_hosts an, so wird der TCPPING-Layer versuchen, mit hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502 zu verbinden. Die Konfigurationsoptionen erlauben, das multiple Nodes auf demselben Host angepingt werden."
+msgstr ""
+"<emphasis role=\"bold\">port_range</emphasis> bestimmt die Anzahl aufeinanderfolgender Ports, die beim Erhalt der ersten Mitgliedschaft geprüft werden, beginnend mit dem im initial_hosts-Parameter spezifizierten Port. Nehmen wir die obigen Werte für port_range und initial_hosts an, so wird der TCPPING-Layer versuchen, mit hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502 zu verbinden. Die Konfigurationsoptionen erlauben es, das multiple Nodes auf demselben Host angepingt werden. "
+"(when getting initial membership, what does that mean?)"
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:381
@@ -1202,7 +1206,7 @@
"when we want TCP as transport, but multicasting for discovery so we don't "
"have to define a static list of initial hosts in TCPPING or require external "
"Gossip Router."
-msgstr "MPING setzt IP-Multicast ein, um die anfängliche Mitgliedschaft festzustellen. Es kann mit allen Transporten verwendet werden, wird jedoch üblicherweise in Kombination mit TCP eingesetzt. TCP erfordert in der Regel TCPPING, welche alle Gruppenmitglieder explizit auflisten muss, aber MPING hat diese Anforderung nicht. Ein typischer Anwendungsfall hierfür besteht, wenn wir TCP als Transport, aber Multicasting für Discovery einsetzen möchten, so dass wir keine statische Liste von initialen Hosts in TCPPING definieren müssen, oder einen externen Gossip-Router benötigen."
+msgstr "MPING setzt IP-Multicast ein, um die Anfangsmitgliedschaft festzustellen. Es kann mit allen Transporten verwendet werden, wird jedoch üblicherweise in Kombination mit TCP eingesetzt. TCP erfordert in der Regel TCPPING, welche alle Gruppenmitglieder explizit auflisten muss, aber MPING stellt diese Anforderung nicht. Ein typischer Anwendungsfall hierfür liegt vor, wenn wir TCP als Transport, aber Multicasting für Discovery einsetzen möchten, so dass wir weder eine statische Liste mit vorhandenen Hosts in TCPPING definieren müssen, noch einen externen Gossip-Router benötigen."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:386
@@ -1250,7 +1254,7 @@
"<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on "
"which to send and receive multicast packets."
msgstr ""
-"<emphasis role=\"bold\">bind_addr</emphasis> bestimmt die Schnittstelle , an der "
+"<emphasis role=\"bold\">bind_addr</emphasis> bestimmt die Schnittstelle, an der "
"Multicast-Pakete gesendet und empfangen werden."
#. Tag: para
@@ -1285,7 +1289,7 @@
"the load balancer and client interceptors know to avoid the dead node. The "
"failure detection protocols are configured as sub-elements in the JGroups "
"MBean <literal>Config</literal> element."
-msgstr "Die Protokolle zur Fehlerermittlung werden zum Auffinden ausgefallener Nodes verwendet. Sobald ein ausgefallener Node ermittelt wurde, kann eine Phase zur Überprüfung des verdächtigten Nodes stattfinden. Wird der Node dann immer noch als ausgefallen betrachtet, dann wird anschließend der Cluster aktualisiert, so dass Lastverteiler und Client-Interzeptoren den ausgefallenen Node meiden können. Die Protokolle zur Fehlerermittlung sind als Unterelemente im JGroups MBean <literal>Config</literal>-Element konfiguriert."
+msgstr "Die Protokolle zur Fehlerermittlung werden zum Auffinden ausgefallener Nodes verwendet. Sobald ein ausgefallener Node ermittelt wurde, kann eine Phase zur Überprüfung des verdächtigten Nodes stattfinden. Gild der Node danach immer noch als ausgefallen, dann wird anschließend der Cluster aktualisiert, so dass Lastverteiler und Client-Interzeptoren den ausgefallenen Node meiden. Die Protokolle zur Fehlerermittlung sind als Unterelemente im JGroups MBean <literal>Config</literal>-Element konfiguriert."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:425
@@ -1304,7 +1308,7 @@
"double check whether the suspected node is indeed dead after which, if the "
"node is still considered dead, updates the cluster's view. Here is an "
"example FD configuration."
-msgstr "Bei FD handelt es sich um ein Protokoll zur Fehlerermittlung basierend auf \"Heartbeat\"-Nachrichten. Dieses Protokoll erfordert von jedem Node, regelmäßige eine Zustandsanfrage (sog. \"are-you-alive\"-Nachrichten) an seinen Nachbar-Node. Falls dieser nicht reagiert, wird eine SUSPECT-Nachricht vom anfragenden Node an den Cluster geschickt. Der aktuelle Gruppenkoordinator kann optional noch einmal überprüfen, ob der verdächtige Node tatsächlich ausgefallen ist. Wenn er den Node danach immer noch als ausgefallen betrachtet, aktualisiert er die Ansicht des Clusters entsprechend. Nachfolgend sehen Sie ein Beispiel für die FD-Konfiguration."
+msgstr "Bei FD handelt es sich um ein Protokoll zur Fehlerermittlung basierend auf \"Heartbeat\"-Nachrichten. Dieses Protokoll erfordert von jedem Node, regelmäßige Zustandsanfragen (sog. \"are-you-alive\"-Nachrichten) an seinen Nachbar-Node zu schicken. Falls dieser nicht reagiert, wird eine SUSPECT-Nachricht vom anfragenden Node an den Cluster geschickt. Der aktuelle Gruppenkoordinator kann optional noch einmal überprüfen, ob der verdächtige Node tatsächlich ausgefallen ist. Wenn der Node danach immer noch als ausgefallen gilt, aktualisiert er die Ansicht des Clusters entsprechend. Nachfolgend sehen Sie ein Beispiel für die FD-Konfiguration."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:430
@@ -1339,7 +1343,7 @@
"default is 3000."
msgstr ""
"<emphasis role=\"bold\">timeout</emphasis> bestimmt die Anzahl von "
-"Millisekunden, die auf Rückmeldung auf die Zustandsanfrage (die \"are-you-alive\"-Nachrichten) gewartet wird. Der Standardwert ist 3000."
+"Millisekunden, die auf Rückmeldung auf die Zustandsanfrage (die \"are-you-alive\"-Nachrichten) gewartet wird. Der voreingestellte Wert lautet 3000."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:440
@@ -1351,11 +1355,12 @@
msgstr ""
"<emphasis role=\"bold\">max_tries</emphasis> bestimmt die Anzahl verpasster "
"Zustandsanfragen eines Nodes, ehe von einem Ausfall desselben ausgegangen "
-"wird. Der voreingestellte Wert ist 2."
+"wird. Der Standardwert ist 2."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:444
#, no-c-format
+#, fuzzy
msgid ""
"<emphasis role=\"bold\">shun</emphasis> specifies whether a failed node will "
"be shunned. Once shunned, the node will be expelled from the cluster even if "
@@ -1363,7 +1368,9 @@
"through the discovery process. JGroups allows to configure itself such that "
"shunning leads to automatic rejoins and state transfer, which is the default "
"behaivour within JBoss Application Server."
-msgstr "<emphasis role=\"bold\">shun</emphasis> bestimmt, ob ein ausgefallener Node gemieden wird. Falls dies der Fall ist, so wird er vom Cluster ausgeschlossen, selbst wenn er später wieder funktioniert. Der ausgeschlossene Node wird erst durch den Discovery-Prozess wieder Teil des Clusters. JGroups erlaubt eine Selbst-Konfiguration in einer Weise, so dass der Ausschluss eines Nodes automatisch zum Wiedereintritt und Statustransfer führt, was das standardmäßige Verhalten im JBoss Anwendungsserver ist."
+msgstr ""
+"<emphasis role=\"bold\">shun</emphasis> bestimmt, ob ein ausgefallener Node gemieden wird. Wird dieser Node einmal gemieden, so wird er vom Cluster ausgeschlossen, selbst wenn er später wieder funktioniert. Der ausgeschlossene Node wird erst durch den Discovery-Prozess wieder Teil des Clusters. JGroups kann sich selbst derart konfigurieren, dass der Ausschluss eines Nodes automatisch zum Wiedereintritt und Statustransfer führt, was das standardmäßige Verhalten im JBoss Anwendungsserver ist. "
+"(does it really configure \"itself\", or is it still the user/admin doing it....?)"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:450
@@ -1386,6 +1393,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:460
#, no-c-format
+#, fuzzy
msgid ""
"FD_SOCK is a failure detection protocol based on a ring of TCP sockets "
"created between group members. Each member in a group connects to its "
@@ -1396,7 +1404,13 @@
"suspected. The simplest FD_SOCK configuration does not take any attribute. "
"You can just declare an empty <literal>FD_SOCK</literal> element in "
"JGroups's <literal>Config</literal> element."
-msgstr "Bei FD_SOCK handelt es sich um ein Protokoll zur Fehlerermittlung basierend auf einem Kreis aus TCP-Sockets zwischen Gruppenmitgliedern. Jedes Mitglied einer Gruppe verbindet sich mit seinem Nachbarn (das letzte Mitglied verbindet sich mit dem ersten) und bildet dadurch einen Kreis. Mitglied B wird verdächtigt, wenn dessen Nachbar A einen regelwidrig geschlossenen TCP-Socket aufspürt (vermutlich aufgrund eines Ausfalls von Node B). Wenn jedoch Mitglied B im Begriff ist, sicher (\"graceful\") zu beenden, informiert es seinen Nachbarn A, damit er nicht verdächtigt wird. Die einfachste FC_SOCK-Konfiguration nimmt kein Attribut. Sie können einfach ein leeres <literal>FD_SOCK</literal>-Element im <literal>Config</literal>-Element von JGroups deklarieren."
+msgstr ""
+"Bei FD_SOCK handelt es sich um ein Protokoll zur Fehlerermittlung basierend auf einem Kreis aus TCP-Sockets zwischen Gruppenmitgliedern. "
+"Jedes Mitglied einer Gruppe verbindet sich mit seinem Nachbarn (das letzte Mitglied verbindet sich mit dem ersten) und bildet dadurch einen Kreis. "
+"Mitglied B wird verdächtigt, wenn dessen Nachbar A einen regelwidrig geschlossenen TCP-Socket aufspürt (vermutlich aufgrund eines Ausfalls von Node B). "
+"Wenn jedoch Mitglied B im Begriff ist, sicher (\"graceful\") zu beenden, informiert es seinen Nachbarn A, damit er nicht verdächtigt wird. "
+"Die einfachste FC_SOCK-Konfiguration nimmt kein Attribut. "
+"Sie können einfach ein leeres <literal>FD_SOCK</literal>-Element im <literal>Config</literal>-Element von JGroups deklarieren."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:464
More information about the jboss-cvs-commits
mailing list