[jboss-cvs] JBossAS SVN: r84706 - 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
Wed Feb 25 02:21:46 EST 2009
Author: hpeters
Date: 2009-02-25 02:21:46 -0500 (Wed, 25 Feb 2009)
New Revision: 84706
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po
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_JMS.po
Log:
translation update in progress
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po 2009-02-25 06:59:06 UTC (rev 84705)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po 2009-02-25 07:21:46 UTC (rev 84706)
@@ -1,24 +1,27 @@
+# translation of Clustering_Guide_Clustered_Singleton_Services.po to
# Language /tmp/mike/JBEAP420/JBAS translations for JBEAP package.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+#
# Automatically generated, 2007.
-#
+# Hedda Peters <hpeters at redhat.com>, 2009.
msgid ""
msgstr ""
-"Project-Id-Version: JBEAP 420\n"
+"Project-Id-Version: Clustering_Guide_Clustered_Singleton_Services\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2001-02-09 01:25+0100\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: none\n"
+"PO-Revision-Date: 2009-02-25 17:19+1000\n"
+"Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
+"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:5
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Clustered Singleton Services"
-msgstr "Geclusterte JMS-Dienste"
+msgstr "Geclusterte Singleton-Dienste"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:6
@@ -32,13 +35,13 @@
"restarted on the new master. Thus, other than a brief interval when one "
"master has stopped and another has yet to take over, the service is always "
"being provided by one but only one node."
-msgstr ""
+msgstr "Ein geclusterter Singleton-Dienst (sog. HA Singleton) ist ein Dienst, der zwar auf mehreren Nodes eines Clusters deployt wird, seinen Dienst aber nur auf einem der Nodes bereitstellt. Der Node, auf dem der Singleton-Dienst ausgeführt wird, wird in der Regel als der \"Master Node\" bezeichnet. Wenn der Master ausfällt oder beendet wird, so wird ein anderer Master aus den verbleibenden Nodes ausgewählt und der Dienst wird wieder gestartet auf dem neuen Master. Abgesehen von einem kurzen Moment, während ein Master bereits beendet ist und der neue erst noch übernehmen muss, wird der Dienst demzufolge immer von (nur) einem Node bereitgestellt."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:9
#, no-c-format
msgid "Topology after the Master Node fails"
-msgstr ""
+msgstr "Topologie nachdem der Master Node ausfällt"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:17
@@ -52,13 +55,13 @@
"different nodes in the cluster start and stop; based on those notifications "
"each node in the cluster can independently (but consistently) determine if "
"it is now the master node and needs to begin providing a service."
-msgstr ""
+msgstr "Der JBoss Applikationsserver (AS) bietet Unterstützung für eine Reihe von Strategien, die Ihnen beim Deployment von geclusterten Singleton-Diensten behilflich sein sollen. In diesem Abschnitt werden wir die verschiedenen Strategien behandeln. Alle dieser Strategien bauen auf dem in der Einführung beschriebenen HAPartition-Dienst auf. Sie sind darauf angewiesen, dass <literal>HAPartition</literal> Benachrichtigungen ausgibt, wenn verschiedene Nodes dem Cluster beitreten oder daraus austreten; basierend auf diesen Benachrichtigungen kann jeder Node im Cluster unabhängig (aber einheitlich) feststellen, ob er nun der Master Node ist und ab jetzt einen Dienst bereitstellen muss."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:22
-#, fuzzy, no-c-format
+#, no-c-format
msgid "HASingletonDeployer service"
-msgstr "client-deployer-service.xml"
+msgstr "HASingletonDeployer-Dienst"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:23
@@ -79,6 +82,8 @@
"service when it stops being the master (typically at server shutdown) is to "
"undeploy the contents of <literal>deploy-hasingleton</literal>."
msgstr ""
+"Die einfachste und gebräuchlichste Strategie zum Deployment eines HA-Singletons besteht darin, ein gewöhnliches Deployment zu nehmen (war, ear, jar, oder was immer Sie üblicherweise in deploy platzieren), und es in dem <literal>$JBOSS_HOME/server/all/deploy-hasingleton</literal>-Verzeichnis zu deployen, statt in <literal>deploy</"
+"literal>. Das <literal>deploy-hasingleton</literal>-Verzeichnis liegt nicht unter deploy oder farm, also werden seine Inhalte nicht automatisch deployt, wenn eine AS-Instanz startet. Stattdessen obliegt es einem speziellen Dienst, die Inhalte dieses Verzeichnisses zu deployen – dem <literal>jboss.ha:service=HASingletonDeployer</literal>-MBean (was wiederum via der deploy/deploy-hasingleton-service.xml-Datei deployt wird). Der HASingletonDeployer-Dienst ist selbst ein HA-Singleton, dessen bereitgestellter Dienst, sobald er Master wird, darin besteht, die Inhalte von deploy-hasingleton zu deployen, und dessen Dienst, sobald er aufhört Master zu sein (normalerweise beim Beenden des Servers), darin besteht, die Inhalte von <literal>deploy-hasingleton</literal> zu un-deployen."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:26
@@ -89,14 +94,13 @@
"the master node cleanly shuts down, they will be cleanly undeployed as part "
"of shutdown. If the master node fails or is shut down, they will be deployed "
"on whatever node takes over as master."
-msgstr ""
+msgstr "Indem Sie also Ihre Deployments in <literal>deploy-hasingleton</literal> platzieren, wissen Sie, dass sie nur auf dem Master Node im Cluster deployt werden. Wenn der Master Node ordnungsgemäß beendet wird, werden sie im Rahmen des Beendigungsprozesses ebenso ordnungsgemäß un-deployt. Falls jedoch der Master Node ausfällt oder geschlossen wird, werden sie auf demjenigen Node deployt werden, der als Master einspringt."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:29
#, no-c-format
-msgid ""
-"Using deploy-hasingleton is very simple, but it does have two drawbacks:"
-msgstr ""
+msgid "Using deploy-hasingleton is very simple, but it does have two drawbacks:"
+msgstr "Die Verwendung von deploy-hasingleton ist sehr einfach, hat jedoch zwei Nachteile:"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:33
@@ -105,7 +109,7 @@
"There is no hot-deployment feature for services in <literal>deploy-"
"hasingleton</literal>. Redeploying a service that has been deployed to "
"<literal>deploy-hasingleton</literal> requires a server restart."
-msgstr ""
+msgstr "Es existiert kein Hot-Deployment-Feature für Dienste in <literal>deploy-hasingleton</literal>. Erneutes Deployment eines Dienstes, der bereits in <literal>deploy-hasingleton</literal> deployt wurde, erfordert einen Neustart des Servers."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:38
@@ -116,13 +120,13 @@
"it will be providing services. Depending on how complex the deployment of "
"your service is and what sorts of startup activities it engages in, this "
"could take a while, during which time the service is not being provided."
-msgstr ""
+msgstr "Wenn der Master Node ausfällt und ein anderer Node als Master übernimmt, muss ihr Singleton-Dienst den gesamten Deployment-Prozess durchlaufen, bevor er Dienste bereitstellt. Abhängig von der Komplexität des Deployment Ihres Dienstes und der Art von Aktivitäten beim Hochfahren, kann dies eine Weile dauern, währenddessen der Dienst nicht bereitgestellt werden kann."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:50
#, no-c-format
msgid "Mbean deployments using HASingletonController"
-msgstr ""
+msgstr "Mbean Deployments unter Verwendung des HASingletonController"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:51
@@ -137,7 +141,7 @@
"on your service telling it to begin providing service. If it determines it "
"is no longer the master node, it invokes a method on your service telling it "
"to stop providing service. Let's walk through an illustration."
-msgstr ""
+msgstr "Falls Ihr Dienst ein MBean ist (d. h. kein J2EE-Deployment wie ein ear, war oder jar), können Sie ihn zusammen mit einem Dienst namens HASingletonController deployen, um es in einen HA-Singleton umzuwandeln. Es ist Aufgabe des HASingletonControllers, den Cluster in Zusammenarbeit mit dem HAPartition-Dienst zu überwachen und zu bestimmen, ob er nun der Master Node für seinen Dienst ist. Falls er feststellt, dass er nun der Master Node ist, ruft er eine Methode an Ihrem Dienst auf und teilt ihm mit, die Bereitstellung des Dienstes zu beginnen. Wenn er feststellt, dass er nicht länger der Master Node ist, ruft er eine Methode an Ihrem Service auf und teilt ihm mit, die Bereitstellung des Dienstes zu beenden. Gehen wir schrittweise ein Beispiel durch."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:54
@@ -147,7 +151,7 @@
"only thing special about it is it needs to expose in its MBean interface a "
"method that can be called when it should begin providing service, and "
"another that can be called when it should stop providing service:"
-msgstr ""
+msgstr "Zunächst einmal haben wir ein MBean-Dienst, den wir zum HA-Singleton machen wollen. Das einzig Besondere daran ist, dass es in seiner MBean-Schnittstelle eine Methode offenlegen muss, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten beginnen soll, sowie einer anderen Methode, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten aufhören soll:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:57
@@ -172,6 +176,24 @@
" } \n"
"} ]]>"
msgstr ""
+"<![CDATA[ \n"
+"public class HASingletonExample\n"
+"implements HASingletonExampleMBean { \n"
+" \n"
+"private boolean isMasterNode = false; \n"
+" \n"
+"public void startSingleton() { \n"
+"isMasterNode = true; \n"
+"} \n"
+". \n"
+"public boolean isMasterNode() { \n"
+"return isMasterNode; \n"
+" } \n"
+" \n"
+" public void stopSingleton() { \n"
+" isMasterNode = false; \n"
+" } \n"
+"} ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:59
@@ -179,7 +201,7 @@
msgid ""
"We used “startSingleton” and “stopSingleton” in the above example, but you "
"could name the methods anything."
-msgstr ""
+msgstr "Wir verwendeten “startSingleton” und “stopSingleton” im obigen Beispiel, aber Sie können diese Methoden beliebig benennen."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:62
@@ -188,7 +210,7 @@
"Next, we deploy our service, along with an HASingletonController to control "
"it, most likely packaged in a .sar file, with the following <literal>META-"
"INF/jboss-service.xml</literal>:"
-msgstr ""
+msgstr "Als nächstes deployen wir unseren Dienst, zusammen mit einem HASingletonController, um ihn zu kontrollieren, vermutlich gepackt in einer .sar-Datei, mit dem folgenden <literal>META-INF/jboss-service.xml</literal>:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:65
@@ -223,12 +245,40 @@
" </mbean> \n"
"</server> ]]>"
msgstr ""
+"<![CDATA[\n"
+" <server> \n"
+" <!-- This MBean is an example of a clustered singleton --> \n"
+" <mbean code=\"org.jboss.ha.examples.HASingletonExample\" \n"
+" name=“jboss:service=HASingletonExample\"/> \n"
+" \n"
+" <!-- This HASingletonController manages the cluster Singleton --> \n"
+" <mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+" name=\"jboss:service=ExampleHASingletonController\"> \n"
+" \n"
+" <!-- Inject a ref to the HAPartition -->\n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-"
+"type=\"attribute\">\n"
+" jboss:service=${jboss.partition.name:"
+"DefaultPartition}\n"
+" </depends> \n"
+" <!-- Inject a ref to the service being controlled -->\n"
+" <depends optional-attribute-name=\"TargetName\">\n"
+" jboss:service=HASingletonExample\n"
+" </depends>\n"
+" <!-- Methods to invoke when become master / stop being "
+"master -->\n"
+" <attribute name=\"TargetStartMethod\">startSingleton</"
+"attribute> \n"
+" <attribute name=\"TargetStopMethod\">stopSingleton</"
+"attribute> \n"
+" </mbean> \n"
+"</server> ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:67
#, no-c-format
msgid "Voila! A clustered singleton service."
-msgstr ""
+msgstr "Fertig! Ein geclusterter Singleton-Dienst."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:69
@@ -243,7 +293,7 @@
"deployed; it doesn't wait until the node becomes the master node. So, the "
"service could be primed and ready to go, just waiting for the controller to "
"implement startSingleton() at which point it can immediately provide service."
-msgstr ""
+msgstr "Ein offensichtlicher Nachteil bei diesem Verfahren ist, dass es nur für MBeans funktioniert. Vorteil ist, dass das obige Beispiel in <literal>deploy</literal> oder <literal>farm</literal> platziert werden kann und dadurch Hot Deployment und Farmed Deployment möglich ist. Auch könnten komplexe, zeitintensive Anforderungen für den Start in unserem Beispiel möglicherweise in create()- oder start()-Methoden implementiert werden. JBoss ruft create() oder start() auf, sobald der Dienst deployt wird; es wartet nicht darauf, dass der Node zum Master Node wird. Also kann der Dienst einsatzbereit sein, und nur darauf warten, dass der Controller startSingleton() implementiert, woraufhin er sofort seinen Dienst bereitstellen kann."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:72
@@ -253,7 +303,7 @@
"an interesting example of using an HASingletonController. Here is its "
"deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
"service.xml</literal> file):"
-msgstr ""
+msgstr "Der oben erläuterte jboss.ha:service=HASingletonDeployer-Dienst ist selbst ein interessantes Beispiel für die Anwendung eines HASingletonControllers. Nachfolgend sehen Sie seinen Deployment-Deskriptor (extrahiert aus der <literal>deploy/deploy-hasingleton-service.xml</literal>-Datei):"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:75
@@ -279,6 +329,25 @@
" </attribute> \n"
"</mbean> ]]>"
msgstr ""
+"<![CDATA[ \n"
+"<mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+"name=\"jboss.ha:service=HASingletonDeployer\"> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-type=\"attribute"
+"\">\n"
+" jboss:service=${jboss.partition.name:DefaultPartition}\n"
+" </depends> \n"
+" <depends optional-attributeame=\"TargetName\">\n"
+" jboss.system:service=MainDeployer\n"
+" </depends> \n"
+" <attribute name=\"TargetStartMethod\">deploy</attribute> \n"
+" <attribute name=\"TargetStartMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+" <attribute name=\"TargetStopMethod\">undeploy</attribute> \n"
+" <attribute name=\"TargetStopMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+"</mbean> ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:77
@@ -296,13 +365,13 @@
"singleton service's start/stop methods can take an argument, in this case "
"the location of the directory the <literal>MainDeployer</literal> should "
"deploy/undeploy."
-msgstr ""
+msgstr "Einige interessante Punkte hier. Erstens handelt es sich bei dem kontrollierten Dienst um den <literal>MainDeployer</literal>-Dienst – der Haupt-Deployment-Dienst in JBoss. Das heißt, dies ist ein Dienst, der nicht in der Absicht geschrieben wurde, ihn von einem <literal>HASingletonController</literal> kontrollieren zu lassen. Und dennoch funktioniert es! Zweitens, die Ziel-Start- und Ziel-Stopmethoden lauten “deploy” und “undeploy”. Keine Anforderung bezüglich bestimmter Namen, oder auch nur dass sie logisch “start” und “stop” Funktionalitäten besitzen. Hier ist die Funktionalität der aufgerufenen Methoden eher “do” und “undo”. Zuguterletzt beachten Sie die “<literal>TargetStart(Stop)MethodArgument</literal>”-Attribute. Die start/stop-Methoden Ihres Singleton-Dienstes können ein Argument übernehmen, in diesem Fall der Speicherort des Verzeichnissses, das der <literal>MainDeployer</literal> deployen/un-deployen soll."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:85
#, no-c-format
msgid "HASingleton deployments using a Barrier"
-msgstr ""
+msgstr "HASingleton Deployments unter Verwendung von \"Barriers\""
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:86
@@ -312,7 +381,7 @@
"stopped whenever the content of deploy-hasingleton gets deployed/undeployed, "
"(i.e., whenever the current node becomes the master), need only specify a "
"dependency on the Barrier mbean:"
-msgstr ""
+msgstr "Ganz normal innerhalb von deploy oder farm deployte Dienste, die gestartet/gestoppt werden wollen, sobald der Inhalt von deploy-hasingleton deployt/un-deployt wird (d. h. jedesmal wenn der aktuelle Node zum Master wird), brauchen nur eine Abhängigkeit auf dem Barrier-MBean festlegen:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:88
@@ -321,6 +390,8 @@
"<![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</"
"depends>]]>"
msgstr ""
+"<![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</"
+"depends>]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:90
@@ -338,7 +409,7 @@
"Barrier MBean using the usual <depends> tag, and they will be started "
"and stopped in tandem with the Barrier. When the BarrierController is "
"undeployed the Barrier is destroyed too."
-msgstr ""
+msgstr "Und so funktioniert es: ein BarrierController wird deployt zusammen mit dem jboss.ha:service=HASingletonDeployer-MBean, und lauscht auf JMX-Benachrichtigungen von dort. Ein BarrierController ist ein vergleichsweise simples MBean, das sich zum Empfang jeglicher JMX-Benachrichtigungen im System anmelden kann. Es verwendet die empfangenen Benachrichtigungen, um den Lebenszyklus eines dynamisch erstellten MBean namens \"Barrier\" zu kontrollieren. Der Barrier wird instanziert, registriert, und auf den CREATE-Zustand gebracht, wenn der BarrierController deployt wird. Anschließend startet und stoppt der BarrierController den Barrier, wenn entsprechende JMX-Benachrichtigungen empfangen werden. Demzufolge brauchen andere Dienste nur vom Barrier-MBean abzuhängen, mittels des üblichen <depends>-Tags, und sie werden zusammen mit dem Barrier gestartet und gestoppt. Wird der BarrierController un-deployt, so wird der Barrier ebenfalls entfernt."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:94
@@ -347,7 +418,7 @@
"This provides an alternative to the deploy-hasingleton approach in that we "
"can use farming to distribute the service, while content in deploy-"
"hasingleton must be copied manually on all nodes."
-msgstr ""
+msgstr "Dies stellt insofern eine Alternative dar zum deploy-hasingleton-Verfahren, als wir nun Farming zum Verteilen des Dienstes nutzen können, während Inhalte in deploy-hasingleton manuell auf alle Nodes kopiert werden muss."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:97
@@ -358,7 +429,7 @@
"on the master node. This is different with the deploy-hasingleton approach "
"that will only deploy (instantiate/create/start) the contents of the deploy-"
"hasingleton directory on one of the nodes."
-msgstr ""
+msgstr "Andererseits wird der Barrier-abhängige Dienst zwar auf allen Nodes instanziert/erstellt (d. h. alle create()-Methoden aufgerufen), aber nur auf dem Master Node gestartet. Dies unterscheidet sich vom deploy-hasingleton-Verfahren, bei dem die Inhalte des deploy-hasingleton-Verzeichnisses nur auf einem der Nodes deployt (instanziert/erstellt/gestartet) wird."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:101
@@ -367,11 +438,11 @@
"So services depending on the barrier will need to make sure they do minimal "
"or no work inside their create() step, rather they should use start() to do "
"the work."
-msgstr ""
+msgstr "Dienste abhängig vom Barrier müssen also sicherstellen, kaum oder gar keine Arbeit innerhalb ihres create()-Schritts auszuführen, sondern sollten stattdessen start() verwenden, um Arbeit auszuführen."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:104
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Note"
msgstr "Anmerkungen"
@@ -385,13 +456,13 @@
"literal> to control services that need to be \"destroyed\" as part of their "
"normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
"literal>) will not have the desired effect."
-msgstr ""
+msgstr "Barrier kontrolliert den Start/Stopp von abhängigen Diensten, aber nicht deren Zerstörung, die nur erfolgt, wenn der <literal>BarrierController</literal> selbst zerstört/un-deployt wird. Daher wird die Verwendung von <literal>Barrier</literal> zum Kontrollieren von Diensten, die als Teil ihrer normalen \"un-deploy\"-Operation \"zerstört\" werden müssen (wie z. B. ein <literal>EJBContainer</literal>), nicht den gewünschten Effekt haben."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:114
#, no-c-format
msgid "Determining the master node"
-msgstr ""
+msgstr "Bestimmen des Master Nodes"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:115
@@ -401,7 +472,7 @@
"that each node in the cluster can independently react to changes in cluster "
"membership and correctly decide whether it is now the “master node”. How is "
"this done?"
-msgstr ""
+msgstr "Die verschiedenen Verwaltungsstrategien für geclusterte Singletons sind alle angewiesen auf die Tatsache, dass jeder Node im Cluster unabhängig auf Änderungen in der Cluster-Mitgliedschaft reagieren und richtig entscheiden kann, ob er jetzt der \"Master Node\" ist. Doch wie funktioniert das?"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:118
@@ -416,7 +487,7 @@
"CurrentView attribute in the <literal>jboss:service=DefaultPartition</"
"literal> mbean. Every member of the cluster will have the same view, with "
"the members in the same order."
-msgstr ""
+msgstr "Vor JBoss AS 4.2.0 war die Methodik hierfür klar und einfach. Für jedes Mitglied im Cluster bewahrt das HAPartition-MBean ein Attribut namens CurrentView, welches im Wesentlichen eine geordnete Liste der aktuellen Mitglieder im Cluster ist. Wenn Nodes dem Cluster beitreten oder aus ihm austreten stellt JGroups sicher, dass alle verbleibenden Mitglieder eine aktualisierte Ansicht erhalten. Sie können die aktuelle Ansicht einsehen, indem Sie in die JMX-Konsole gehen und sich das CurrentView-Attribut im <literal>jboss:service=DefaultPartition</literal>-MBean ansehen. Jedes Mitglied des Clusters wird dieselbe Ansicht besitzen, mit denselben Mitgliedern, in derselben Reihenfolge."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:121
@@ -427,7 +498,7 @@
"the order of nodes in the view will reflect the order in which they joined "
"the cluster (although this is not always the case, and should not be assumed "
"to be the case.)"
-msgstr ""
+msgstr "Nehmen wir beispielsweise an, wir haben einen Cluster bestehend aus vier Nodes, Nodes A bis D, und die aktuelle Ansicht kann als {A, B, C, D} angegeben werden. Im Allgemeinen spiegelt die Reihenfolge der Nodes in dieser Ansicht die Reihenfolge wider, in der sie dem Cluster beigetreten sind (dies ist jedoch nicht immer der Fall, und sollte nicht einfach angenommen werden)."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:124
@@ -440,7 +511,7 @@
"are deployed where, in view order. So, on every node in the cluster, the "
"<literal>HAPartition</literal> service knows that the view with respect to "
"the Foo service is {A, C, D} (no B)."
-msgstr ""
+msgstr "Um unser Beispiel auszuweiten, lassen Sie uns nun weiter annehmen, dass es einen Singleton-Dienst (d. h. einen <literal>HASingletonController</literal>) namens Foo gibt, der im gesamten Cluster deployt ist mit Ausnahme von B, aus welchem Grund auch immer. Der <literal>HAPartition</literal>-Dienst pflegt über den gesamten Cluster hinweg eine Registry, welche Dienste wo deployt sind, in der Reihenfolge ihres Auftretens. Auf jedem Node im Cluster weiß der <literal>HAPartition</literal>-Dienst also, dass die Ansicht im Hinblick auf den Foo-Dienst {A, C, D} lautet, ohne B."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:128
@@ -454,7 +525,7 @@
"independently decide if it is now the master. The Foo service on each node "
"does this by checking if they are the first member of the view – if they "
"are, they are the master; if not, they're not. Simple as that."
-msgstr ""
+msgstr "Wann immer eine Änderung an der Cluster-Topologie des Foo-Dienstes erfolgt, ruft der <literal>HAPartition</literal>-Dienst einen Callback auf Foo auf, um über die neue Topologie zu informieren. Als beispielsweise also Foo auf D startete, erhielten die Foo-Dienste auf A, C und D Callbacks, die ihnen die neue Ansicht für Foo {A, C, D} mitteilten. Dieser Callback liefert jedem Node genügend Informationen, um zu entscheiden, ob er nun der Master ist. Der Foo-Dienst tut dies, indem er überprüft, ob er das erste Mitglied in der Ansicht ist – wenn er es ist, so ist er der Master; wenn nicht, dann ist er es nicht. So einfach."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:132
@@ -465,4 +536,5 @@
"A, C and D would get a callback with a new view for Foo of {C, D, A}. C "
"would remain the master – there's nothing magic about A that would cause it "
"to become the master again just because it was before."
-msgstr ""
+msgstr "Falls A nun ausfällt oder beendet wird, erhält Foo auf C und D einen Callback mit der neuen Ansicht für Foo {C, D}. C wird daraufhin zum Master. Falls A neu startet, erhalten A, C und D einen Callback mit der neuen Ansicht für Foo {C, D, A}. C bleibt weiterhin Master – A wird nicht plötzlich durch einen Trick wieder Master, nur weil er das vorher auch war."
+
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po 2009-02-25 06:59:06 UTC (rev 84705)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po 2009-02-25 07:21:46 UTC (rev 84706)
@@ -9,7 +9,7 @@
"Project-Id-Version: Clustering_Guide_Intro\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-22 17:40+1000\n"
+"PO-Revision-Date: 2009-02-25 16:48+1000\n"
"Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
@@ -48,7 +48,7 @@
"Clustering is crucial for highly available enterprise applications, as it is "
"the clustering infrastructure that supports the redundancy needed for high "
"availability."
-msgstr "Mit Clustering (\"Gruppierung\") ist die Ausführung einer Anwendung auf mehreren parallel laufenden Servern (sog. \"Cluster-Nodes\" oder \"Cluster-Knoten\") möglich, während den Anwendungs-Clients eine einheitliche Ansicht geboten wird. Die Auslastung wird dabei auf verschiedene Server verteilt, und selbst falls es zu einer Störung auf einem oder mehreren der Server kommt, ist die Anwendung über andere, nicht betroffene Cluster-Nodes nach wie vor zugänglich. Clustering ist von maßgeblicher Bedeutung für skalierbare Anwendungen eines Unternehmens, da die Leistung ganz bequem durch Hinzufügen weiterer Nodes (\"Knoten\") zum Cluster erhöht werden kann. Clustering ist ebenfalls entscheidend für hochverfügbare Anwendungen einer Unternehmens, denn die Clustering-Infrastruktur unterstützt die Redundanz, die für hohe Verfügbarkeit erforderlich ist."
+msgstr "Mit Clustering (\"Gruppierung\") ist die Ausführung einer Anwendung auf mehreren parallel laufenden Servern (sog. \"Cluster-Nodes\" oder \"Cluster-Knoten\") möglich, während den Anwendungs-Clients ein einheitlicher View geboten wird. Die Auslastung wird dabei auf verschiedene Server verteilt, und selbst falls es zu einer Störung auf einem oder mehreren der Server kommt, ist die Anwendung über andere, nicht betroffene Cluster-Nodes nach wie vor zugänglich. Clustering ist von maßgeblicher Bedeutung für skalierbare Anwendungen eines Unternehmens, da die Leistung ganz bequem durch Hinzufügen weiterer Nodes (\"Knoten\") zum Cluster erhöht werden kann. Clustering ist ebenfalls entscheidend für hochverfügbare Anwendungen einer Unternehmens, denn die Clustering-Infrastruktur unterstützt die Redundanz, die für hohe Verfügbarkeit erforderlich ist."
#. Tag: para
#: Clustering_Guide_Intro.xml:14
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-02-25 06:59:06 UTC (rev 84705)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po 2009-02-25 07:21:46 UTC (rev 84706)
@@ -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-24 17:12+1000\n"
+"PO-Revision-Date: 2009-02-25 09:40+1000\n"
"Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
@@ -723,7 +723,6 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:203
#, no-c-format
-#, fuzzy
msgid ""
"<emphasis role=\"bold\">use_send_queues</emphasis> specifies whether to use "
"separate send queues for each connection. This prevents blocking on write if "
@@ -1501,7 +1500,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:515
#, no-c-format
msgid "A member will be suspected when suspended in a debugger/profiler."
-msgstr ""
+msgstr "Ein Mitglied wird verdächtigt werden, wenn er durch einen Debugger/Profiler ausgesetzt wird."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:520
@@ -1529,7 +1528,7 @@
msgid ""
"Suspended in a debugger is no problem because the TCP connection is still "
"open."
-msgstr ""
+msgstr "Aussetzen durch einen Debugger stellt kein Problem dar, denn die TCP-Verbindung bleibt geöffnet."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:543
@@ -2869,7 +2868,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 "Mitunter wird ein Mitglied von FD verdächtigt, weil seit einer bestimmten Zeit T (definiert durch timeout und max_tries) kein Heartbeack ACK mehr empfangen wurde. Dies kann mehrere Gründe haben, z. B. kann in einem Cluster bestehend aus A,B,C und D, D verdächtigt werden, wenn (beachten Sie, A pingt B, B pingt C, C pingt D und D pingt A):"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1043
@@ -2877,19 +2876,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 oder C werden seit mehr als T Sekunden mit 100% des CPU ausgeführt. Selbst wenn C ein Heartbeat ACK an B sendet, kann B diesen ggf. nicht verarbeiten, da er bei 100% steht."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1048
#, no-c-format
msgid "B or C are garbage collecting, same as above."
-msgstr ""
+msgstr "B oder C führen Speicherbereinigung aus; wie oben."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1053
#, no-c-format
msgid "A combination of the 2 cases above"
-msgstr "Eine Kombination der beiden oben genannten Fälle"
+msgstr "Eine Kombination der beiden oben genannten Fälle."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1058
@@ -2898,7 +2897,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 "Das Netzwerk verliert Pakete. Das passiert gewöhnlich, wenn viel Verkehr im Netzwerk ist, und der Switch anfängt Pakete zu verwerfen (in der Regel Broadcasts zuerst, dann IP-Multicasts, und zuletzt TCP-Pakete)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1063
@@ -2908,5 +2907,5 @@
"over its channel and takes T+1 seconds to process it. During this time, C "
"will not process any other messages, including heartbeats, and therefore B "
"will not receive the heartbeat ack and will suspect C."
-msgstr ""
+msgstr "B oder C verarbeiten einen Callback. Angenommen C hat über seinen Channel einen entfernten Methodenaufruf empfangen und benötigt T+1 Sekunde für dessen Verarbeitung. Während dieser Zeit wird C keinerlei andere Nachrichten verarbeiten, einschließlich Heartbeats. Infolgedessen empfängt B keinen Heartbeat ACK und verdächtigt daher C."
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po 2009-02-25 06:59:06 UTC (rev 84705)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po 2009-02-25 07:21:46 UTC (rev 84706)
@@ -1,18 +1,21 @@
+# translation of Clustering_Guide_JMS.po to
# Language /tmp/mike/JBEAP420/JBAS translations for JBEAP package.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
+#
# Automatically generated, 2007.
-#
+# Hedda Peters <hpeters at redhat.com>, 2009.
msgid ""
msgstr ""
-"Project-Id-Version: JBEAP 420\n"
+"Project-Id-Version: Clustering_Guide_JMS\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2001-02-09 01:25+0100\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: none\n"
+"PO-Revision-Date: 2009-02-25 13:47+1000\n"
+"Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
+"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
#. Tag: title
#: Clustering_Guide_JMS.xml:5
@@ -31,7 +34,7 @@
msgstr ""
"JBoss AS 3.2.4 und spätere Versionen unterstützen \"High Availability\"-JMS "
"(HA-JMS) Dienste in der <literal>all</literal>-Serverkonfiguration. In der "
-"aktuellen Version des JBoss AS, ist der HA-JMS Dienst als geclusterter "
+"aktuellen Produktionsversion des JBoss AS ist der HA-JMS-Dienst als geclusterter "
"Singleton Fail-Over-Dienst implementiert."
#. Tag: para
@@ -57,17 +60,17 @@
"JBoss Messaging project. JBoss Messaging's clustering implementation is "
"considerably different from HA-JMS based on JBoss MQ; most notably it is not "
"based on a singleton service only running on one node in the cluster."
-msgstr ""
+msgstr "Der HA-JMS in JBoss AS 4.2.2 und früheren Versionen basiert auf dem JBoss MQ Messaging-Produkt. In späteren Versionen des AS wird JBoss MQ durch das neuere JBoss Messaging-Projekt ersetzt. Die Clustering-Implementierung in JBoss Messaging unterscheidet sich deutlich von dem auf JBoss MQ basierenden HA-JMS; insbesondere basiert es nicht auf einem Singleton-Dienst, der nur auf einem einzigen Node im Cluster ausgeführt wird."
#. Tag: title
#: Clustering_Guide_JMS.xml:25
#, no-c-format
msgid "High Availability Singleton Fail-over"
-msgstr "Der \"High Availability Singleton Fail-over\""
+msgstr "Der \"High Availability Singleton Fail-Over\""
#. Tag: para
#: Clustering_Guide_JMS.xml:26
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The JBoss HA-JMS service (i.e., message queues topics and supporting "
"services) only runs on a single node (i.e., the master node) in the cluster "
@@ -77,12 +80,8 @@
"against server failures but does not reduce the work load on the JMS server "
"node."
msgstr ""
-"Der JBoss HA-JMS Dienst (d.h. Message Queues und Topics) wird zu einem "
-"beliebigen Zeitpunkt stets nur auf einem einzelnen Node (d.h. dem \"Master-"
-"Node\") im Cluster ausgeführt. Falls dieser Node ausfällt, wählt der Cluster "
-"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Fail-"
-"Over). Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt "
-"jedoch nicht die Arbeitsbelastung am JMS Server-Node."
+"Der JBoss HA-JMS-Dienst (d. h. Message Queues, Topics und unterstützende Dienste) wird zu jedem Zeitpunkt stets nur auf einem einzelnen Node (d. h. dem \"Master Node\") im Cluster ausgeführt. Falls dieser Node ausfällt, wählt der Cluster "
+"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Fail-Over), und die Queues, Topics und unterstützende Dienste werden auf jenem Server deployt. Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt jedoch nicht die Arbeitsbelastung am JMS-Server-Node."
#. Tag: para
#: Clustering_Guide_JMS.xml:28
@@ -92,8 +91,8 @@
"that runs the queues), you can load balance the MDBs that process messages "
"from those queues (see <xref linkend=\"clustering-jms-loadbalanced\"/>)."
msgstr ""
-"Während Sie bei HA-JMS Queues keine Lastverteilung anwenden können (es "
-"existiert nur ein Master-Node, der die Queues ausführt), können Sie die "
+"Während Sie bei HA-JMS-Queues keine Lastverteilung anwenden können (es "
+"existiert nur ein Master Node, der die Queues ausführt), können Sie die "
"MDBs, die die Nachrichten dieser Queues verarbeitet, lastverteilen (siehe "
"<xref linkend=\"clustering-jms-loadbalanced\"/>)."
@@ -116,11 +115,11 @@
"JMS (e.g., MDBs and other JMS clients) do not need to be deployed in deploy-"
"hasingleton. They should only be deployed there if you only want them "
"running on one node in the cluster at a time."
-msgstr ""
+msgstr "Der größte Konfigurationsunterschied zwischen HA-JMS in der all-Konfiguration und der nicht-HA-Version, die sich in der Standardkonfiguration befindet, besteht im Speicherort der meisten Konfigurationsdateien. Für HA-JMS befinden sich die meisten Konfigurationsdateien in dem deploy-hasingleton/jms-Verzeichnis, nicht in deploy/jms. Ihre Queues und Topics müssen im deploy-hasingleton (oder ein Unterverzeichnis davon, wie deploy-hasingleton/jms) deployt werden. Anwendungskomponenten, die als Clients für HA-JMS fungieren (z. B. MDBs und andere JMS-Clients), brauchen nicht in deploy-hasingleton deployt werden. Diese sollten dort nur dann deployt werden, falls Sie wünschen, dass diese jeweils auf einem einzigen Node im Cluster ausgeführt werden."
#. Tag: para
#: Clustering_Guide_JMS.xml:38
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"To use the singleton fail-over HA-JMS service, you must configure JMS "
"services identically on all nodes in the cluster. That includes all JMS "
@@ -128,14 +127,13 @@
"applications that use JMS (e.g., MDBs and other JMS clients) do not need to "
"be deployed identically across the cluster."
msgstr ""
-"Um den Singleton Fail-Over HA-JMS Dienst zu verwenden, müssen Sie die JMS-"
+"Um den Singleton Fail-Over HA-JMS-Dienst zu verwenden, müssen Sie die JMS-"
"Dienste auf sämtlichen Nodes des Clusters identisch konfigurieren. Das "
-"beinhaltet alle JMS bezogenen Service-MBeans und alle deployten JMS-"
-"Anwendungen."
+"beinhaltet alle JMS-bezogenen Service-MBeans und alle deployten Queues und Topics. Alle Anwendungen, die JMS verwenden (z. B. MDBs und andere JMS-Clients) müssen indes nicht im gesamten Cluster identisch deployt sein."
#. Tag: para
#: Clustering_Guide_JMS.xml:44
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The JMS server is configured to persist its data in the <literal>DefaultDS</"
"literal>. By default, that is the embedded HSQLDB. However, for the HA-JMS "
@@ -145,13 +143,7 @@
"any cluster environments, all nodes need to persist data against a shared "
"database. So, the first thing to do before you start clustered JMS is to "
"setup a shared database for JMS. You need to do the following:"
-msgstr ""
-"Der JMS Server ist so konfiguriert, dass er seine Daten im "
-"<literal>DefaultDS</literal> behält. In der Standardeinstellung ist das der "
-"eingebettete (\"embedded\") HSQLDB. In den meisten Clusterumgebungen jedoch "
-"müssen alle Nodes Daten gegen eine gemeinsame Datenbank halten. Ehe Sie also "
-"einen geclusterten JMS starten, müssen Sie eine gemeinsame Datenbank für JMS "
-"einrichten. Hierzu müssen Sie folgendes tun:"
+msgstr "Der JMS-Server ist so konfiguriert, dass er seine Daten im <literal>DefaultDS</literal> behält. In der Standardeinstellung ist das der eingebettete (\"embedded\") HSQLDB. Damit der HA-JMS-Dienst Fail-Over funktionieren kann, muss der neu gestartete HA-JMS-Server die vom alten Server gespeicherten Daten finden können. Dies ist wahrscheinlich nicht möglich, wenn die Daten in Dateien gespeichert wurden, die durch den HSQLDB des alten Servers geschrieben wurden. In den meisten Cluster-Umgebungen müssen alle Nodes Daten auf einer gemeinsamen Datenbank halten. Ehe Sie also einen geclusterten JMS starten, müssen Sie eine gemeinsame Datenbank für JMS einrichten. Hierzu müssen Sie folgendes tun:"
#. Tag: para
#: Clustering_Guide_JMS.xml:50
@@ -162,7 +154,7 @@
"file with the <literal>xxx-ds.xml</literal> file in the <literal>docs/"
"examples/jca</literal> directory, where <literal>xxx</literal> is the name "
"of the target shared database (e.g., <literal>mysql-ds.xml</literal>)."
-msgstr ""
+msgstr "Konfigurieren Sie <literal>DefaultDS</literal> so, dass es auf den Datenbankserver Ihrer Wahl verweist. Das heißt, ersetzen Sie die <literal>deploy/hsqlsb-ds.xml</literal>-Datei durch die <literal>xxx-ds.xml</literal>-Datei im <literal>docs/examples/jca</literal>-Verzeichnis, wobei <literal>xxx</literal> für den Namen der gemeinsamen Zieldatenbank steht (z. B. <literal>mysql-ds.xml</literal>)."
#. Tag: para
#: Clustering_Guide_JMS.xml:57
@@ -179,13 +171,11 @@
"im<literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis mit einer "
"speziell auf Ihre Bedürfnisse abgestimmten. Wenn Sie zum Beispiel MySQL "
"verwenden, so heißt die Datei <literal>mysql-jdbc2-service.xml</literal>. "
-"Die Konfigurationsdateien für eine Reihe von RDBMS sind mit der JBoss AS "
-"Distribution gebündelt. Sie finden diese unter <literal>docs/examples/jms</"
-"literal>."
+"Die Konfigurationsdateien für eine Reihe von RDBMS sind mit der JBoss AS-Distribution gebündelt. Sie finden diese unter <literal>docs/examples/jms</literal>."
#. Tag: para
#: Clustering_Guide_JMS.xml:66
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"There is no need to replace the <literal>hsqldb-jdbc-state-service.xml</"
"literal> file under the <literal>server/all/deploy-hasingleton/jms</literal> "
@@ -193,20 +183,13 @@
"all SQL92 compliant databases, including HSQL, MySQL, SQL Server, and more. "
"It automatically uses the <literal>DefaultDS</literal> for storage, which we "
"configured above."
-msgstr ""
-"Die <literal>hsqldb-jdbc-state-service.xml</literal>-Datei im "
-"<literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis muss nicht "
-"ersetzt werden. Trotz des <literal>hsql</literal> in ihrem Namen "
-"funktioniert sie mit allen SQL92-konformen Datenbanken, einschließlich HSQL, "
-"MySQL, SQL-Server und einigen anderen. Zur Speicherung wird automatisch "
-"<literal>DefaultDS</literal> verwendet, wie wir es weiter oben konfiguriert "
-"haben."
+msgstr "Die <literal>hsqldb-jdbc-state-service.xml</literal>-Datei im <literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis muss nicht ersetzt werden. Trotz des <literal>hsql</literal> in ihrem Namen funktioniert sie mit allen SQL92-konformen Datenbanken, einschließlich HSQL, MySQL, SQL-Server und anderen. Zur Speicherung wird automatisch <literal>DefaultDS</literal> verwendet, wie wir es weiter oben konfiguriert haben."
#. Tag: title
#: Clustering_Guide_JMS.xml:77
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Non-MDB HA-JMS Clients"
-msgstr "Der HA-JMS Client"
+msgstr "Nicht-MDB HA-JMS-Clients"
#. Tag: para
#: Clustering_Guide_JMS.xml:79
@@ -226,7 +209,7 @@
"and topicsusing HA-JNDI (the default port is 1100). This ensures the factory/"
"queue/topic can be found no matter which cluster node is running the HA-JMS "
"server."
-msgstr ""
+msgstr "Der HA-JMS-Client muss sowohl JMS-Verbindungs-Factorys als auch Queues und Topics mittels HA-JNDI auffinden (der Standard-Port ist 1100). Das gewährleistet, dass die Factory/Queue/Topic gefunden werden kann, unabhängig davon, auf welchem Cluster Node der HA-JMS-Server ausgeführt wird."
#. Tag: para
#: Clustering_Guide_JMS.xml:91
@@ -236,7 +219,7 @@
"inside the AS, the lookup via HA-JNDI can be configured using the "
"component's deployment descriptors: In the standard deployment descriptor "
"(ejb-jar.xml or web.xml):"
-msgstr ""
+msgstr "Falls es sich beim Client um eine J2EE-Komponente handelt (Session Bean oder Web-Applikation), die im AS ausgeführt wird, kann der Lookup via HA-JNDI konfiguriert werden mittels des Deployment-Deskriptors der Komponente: In dem Standard-Deployment-Deskriptor (ejb-jar.xml or web.xml):"
#. Tag: programlisting
#: Clustering_Guide_JMS.xml:99
@@ -256,12 +239,25 @@
"</resource-ref>\n"
"]]>"
msgstr ""
+"<![CDATA[\n"
+"<resource-ref>\n"
+" <res-ref-name>jms/ConnectionFactory</res-ref-name>\n"
+" <res-type>javax.jms.QueueConnectionFactory</res-type>\n"
+" <res-auth>Container</res-auth>\n"
+"</resource-ref>\n"
+" \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/Queue</res-ref-name>\n"
+" <res-type>javax.jms.Queue</res-type>\n"
+" <res-auth>Container</res-auth>\n"
+"</resource-ref>\n"
+"]]>"
#. Tag: para
#: Clustering_Guide_JMS.xml:101
#, no-c-format
msgid "And in the JBoss-specific descriptor (jboss.xml or jboss-web.xml):"
-msgstr ""
+msgstr "Und in dem JBoss-spezifischen Deskriptor (jboss.xml or jboss-web.xml):"
#. Tag: programlisting
#: Clustering_Guide_JMS.xml:105
@@ -281,6 +277,19 @@
" <jndi-name>jnp://localhost:1100/queue/A</jndi-name>\n"
"</resource-ref>]]>"
msgstr ""
+"<![CDATA[ \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/ConnectionFactory</res-ref-name>\n"
+" <!-- Use the JMS Resource Adapter, let it deal\n"
+" with knowing where the JMS server is -->\n"
+" <jndi-name>java:/JmsXA</jndi-name>\n"
+" </resource-ref>\n"
+" \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/Queue</res-ref-name>\n"
+" <!-- Use HA-JNDI so we can find the queue on any node -->\n"
+" <jndi-name>jnp://localhost:1100/queue/A</jndi-name>\n"
+"</resource-ref>]]>"
#. Tag: para
#: Clustering_Guide_JMS.xml:110
@@ -292,7 +301,7 @@
"logic. If the HA-JMS service fails over to a different master node, all "
"client operations on the current connection will fail with a JMSException. "
"To deal with this:"
-msgstr ""
+msgstr "Der JA-JMS-Client muss mit Ausnahmen umgehen können, die auf der JMS-Verbindung auftreten, falls ein Server-Failover erfolgt. Anders als z. B. geclusterte EJB-Proxys beinhaltet das JMS-Verbindungsobjekt keine Logik zum automatischen Failover. Falls ein Failover des JA-JMS-Dienstes auf einen anderen Master Node erfolgt, werden alle Client-Operationen auf der aktuellen Verbindung mit einer JMSException fehlschlagen. Um hiermit umzugehen:"
#. Tag: para
#: Clustering_Guide_JMS.xml:118
@@ -303,7 +312,7 @@
"find the JBoss JMS Resource Adapter; the resource adapter will handle the "
"task of detecting server failover and reconnecting to the new server when it "
"starts."
-msgstr ""
+msgstr "Wenn der Client innerhalb des Applikations-Servers ausgeführt wird, sollte der Client die ConnectionFactory erhalten durch Aufsuchen von java:/JmsXA in JNDI. Dies wird den JBoss JMS-Ressourcenadapter finden; der Ressourcenadapter übernimmt dann die Aufgabe, den Server-Failover zu erkennen und mit dem neu gestarteten Server zu verbinden."
#. Tag: para
#: Clustering_Guide_JMS.xml:122
@@ -315,7 +324,7 @@
"the task of closing the old connection and reconnecting. Following is a "
"example application that continuously sends messages to a queue, handling "
"any exceptions that occur:"
-msgstr ""
+msgstr "Für Clients außerhalb des Anwendungsservers ist die beste Methode, einen ExceptionListener bei der Verbindung zu registrieren; der Listener erhält einen Callback, falls eine Ausnahme auf der Verbindung auftritt. Der Callback übernimmt dann die Aufgabe, die alte Verbindung zu beenden und neu zu verbinden. Nachfolgend sehen Sie eine Beispielanwendung, die kontinuierlich Nachrichten an eine Queue sendet, und handhabt jegliche auftretende Ausnahmen:"
#. Tag: programlisting
#: Clustering_Guide_JMS.xml:128
@@ -482,12 +491,172 @@
"}\n"
"]]>"
msgstr ""
+"<![CDATA[\n"
+"package com.test.hajms.client;\n"
+"\n"
+"import javax.naming.InitialContext;\n"
+"import javax.jms.ConnectionFactory;\n"
+"import javax.jms.Destination;\n"
+"import javax.jms.Connection;\n"
+"import javax.jms.Session;\n"
+"import javax.jms.MessageProducer;\n"
+"import javax.jms.Message;\n"
+"import javax.jms.ExceptionListener;\n"
+"import javax.jms.JMSException;\n"
+"import javax.jms.DeliveryMode;\n"
+"\n"
+"import org.apache.commons.logging.Log;\n"
+"import org.apache.commons.logging.LogFactory;\n"
+" \n"
+"public class FailoverJMSClient\n"
+"{\n"
+"private static final Log log = LogFactory.getLog(FailoverJMSClient.class);\n"
+"\n"
+"public static final int NUM_RETRIES = 3;\n"
+"\n"
+"volatile boolean doSend = true;\n"
+"ConnectionFactory connectionFactory;\n"
+"Destination queue;\n"
+"Connection connection;\n"
+"Session session;\n"
+"MessageProducer producer;\n"
+"\n"
+"\n"
+"public static void main(String[] args) throws Exception\n"
+"{\n"
+"FailoverJMSClient jmsClient = new FailoverJMSClient();\n"
+"jmsClient.setUpJMS();\n"
+"jmsClient.sendMessages();\n"
+"}\n"
+"\n"
+"\n"
+"public boolean setUpJMS()\n"
+"{\n"
+"InitialContext ic;\n"
+"try\n"
+"{\n"
+"// assume jndi.properties is configured for HA-JNDI\n"
+"ic = new InitialContext();\n"
+"connectionFactory = (ConnectionFactory)ic.lookup(\"ConnectionFactory\");\n"
+"queue = (Destination)ic.lookup(\"queue/FailoverTestQueue\");\n"
+"connection = connectionFactory.createConnection();\n"
+"try\n"
+"{\n"
+"log.debug(\"Connection created ...\");\n"
+"\n"
+"// KEY - register for exception callbacks\n"
+"connection.setExceptionListener(new ExceptionListenerImpl());\n"
+"\n"
+"session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);\n"
+"log.debug(\"Session created ...\");\n"
+"producer = session.createProducer(queue);\n"
+"\n"
+"producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);\n"
+"log.debug(\"Producer created ...\");\n"
+"\n"
+"return true;\n"
+"}\n"
+"catch (Exception e)\n"
+"{\n"
+"// We failed so close the connection\n"
+"try\n"
+"{\n"
+"connection.close();\n"
+"}\n"
+"catch (JMSException ignored)\n"
+"{\n"
+"// Pointless\n"
+"}\n"
+"// Rethrow the initial problem to where we will log it\n"
+"throw e;\n"
+"} \n"
+"finally\n"
+"{\n"
+"// And close the initial context\n"
+"// We don't want to wait for the garbage collector to close it\n"
+"// otherwise we'll have useless hanging network connections\n"
+"ic.close();\n"
+"}\n"
+"}\n"
+"catch (Exception e)\n"
+"{\n"
+"log.error(\"Error setting up JMS\", e);\n"
+"return false;\n"
+"}\n"
+"}\n"
+"\n"
+"public void sendMessages()\n"
+"{\n"
+"int cnt = 0;\n"
+"while(doSend)\n"
+"{\n"
+"try\n"
+"{\n"
+"Thread.sleep(100);\n"
+"\n"
+"Message m = session.createObjectMessage(new Integer(cnt++));\n"
+"producer.send(m);\n"
+"\n"
+"log.trace(\"message \" + cnt + \" sent\");\n"
+"\n"
+"}\n"
+"catch(Exception e)\n"
+"{\n"
+"cnt--;\n"
+"log.error(e.getMessage());\n"
+"}\n"
+"}\n"
+"}\n"
+"\n"
+"\n"
+"\n"
+"private class ExceptionListenerImpl implements ExceptionListener\n"
+"{\n"
+"public void onException(JMSException e)\n"
+"{\n"
+" \n"
+"for(int i = 0; i < NUM_RETRIES; i++)\n"
+" {\n"
+" log.warn(\"Connection has problems, trying to re-create it, "
+"attempt \" +\n"
+" (i + 1) + \" ...\");\n"
+" \n"
+" try \n"
+" {\n"
+" connection.close(); // unregisters the ExceptionListener\n"
+" }\n"
+" catch(Exception e2) {\n"
+" // I will get an Exception anyway, since the connection to "
+"the \n"
+" //server is broken, but close() frees up resources associated \n"
+" // with the connection\n"
+" }\n"
+" \n"
+" boolean setupOK = setUpJMS();\n"
+" \n"
+" if (setupOK)\n"
+" {\n"
+" log.info(\"Connection re-established\");\n"
+" return;\n"
+" }\n"
+" else\n"
+" {\n"
+" log.warn(\"Re-creating connection failed, retrying ...\");\n"
+" }\n"
+" }\n"
+" \n"
+" log.error(\"Cannot re-establish connection, giving up ...\");\n"
+" doSend = false;\n"
+" }\n"
+" }\n"
+"}\n"
+"]]>"
#. Tag: title
#: Clustering_Guide_JMS.xml:132
#, no-c-format
msgid "MDBs and HA-JMS Failover"
-msgstr ""
+msgstr "MDBs und HA-JMS Failover"
#. Tag: para
#: Clustering_Guide_JMS.xml:133
@@ -496,7 +665,7 @@
"When you deploy an MDB in JBoss, JBoss' MDB container handles for you all "
"issues associated with finding the cluster singleton HA-JMS server and with "
"reconnecting to it if it fails over."
-msgstr ""
+msgstr "Wenn Sie eine MDB in JBoss deployen, übernimmt der JBoss MDB-Container sämtliche Aufgaben bezüglich der Suchen des Cluster-Singleton HA-JMS-Servers undder Neuverbindung im Falle eines Fail-Overs. "
#. Tag: title
#: Clustering_Guide_JMS.xml:143
@@ -518,10 +687,10 @@
msgstr ""
"Während HA-JMS Queues und Topics jeweils nur an einem einzelnen Node "
"ausgeführt werden, können MDBs an mehreren Nodes Nachrichten vom HA-JMS "
-"Master-Node empfangen und bearbeiten. Die zweifelhaften Queues und Topics "
+"Master Node empfangen und bearbeiten. Die zweifelhaften Queues und Topics "
"resultieren im lastverteilten Verhalten der MDBs. Um die Lastverteilung für "
"MDBs zu aktivieren, können Sie einen Receiver für die Queue bestimmen. Der "
-"Receiver protokolliert welcher Node auf Nachricht wartet und in welcher "
+"Receiver protokolliert, welcher Node auf Nachricht wartet und in welcher "
"Reihenfolge Nachrichten bearbeitet werden sollten. JBoss bietet drei "
"Receiver-Implementierungen."
@@ -531,13 +700,11 @@
msgid ""
"The <literal>org.jboss.mq.server.ReceiversImpl</literal> is the default "
"implementation using a <literal>HashSet</literal>."
-msgstr ""
-"Die Standard-Implementierung ist <literal>org.jboss.mq.server.ReceiversImpl</"
-"literal> unter Verwendung von <literal>HashSet</literal>."
+msgstr "Die Standardimplementierung ist <literal>org.jboss.mq.server.ReceiversImpl</literal> unter Verwendung von <literal>HashSet</literal>."
#. Tag: para
#: Clustering_Guide_JMS.xml:155
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The <literal>org.jboss.mq.server.ReceiversImplArrayList</literal> is the "
"implementation using an <literal>ArrayList</literal>."
@@ -566,4 +733,5 @@
"literal> or <literal>ReceiversImplLinkedList</literal> implementations due "
"to an undesirable implementation detail of <literal>HashSet</literal> in the "
"JVM."
-msgstr ""
+msgstr "Sie können den Klassennamen der Receiver-Implementierung als ein Attribut in dem MBean festlegen, das die permanente JMS-<literal>Queue</literal> oder <literal>DestinationManager</literal> auf jedem Node definiert. Für optimale Leistung der Lastverteilung empfehlen wir die Verwendung der <literal>ReceiversImplArrayList</literal> oder <literal>ReceiversImplLinkedList</literal>-Implementierung, aufgrund eines unerwünschten Implementierungsdetails von <literal>HashSet</literal> in der JVM."
+
More information about the jboss-cvs-commits
mailing list