[jboss-cvs] JBossAS SVN: r84913 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/es-ES.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Mar 2 00:52:08 EST 2009
Author: agarcia at jboss.com
Date: 2009-03-02 00:52:08 -0500 (Mon, 02 Mar 2009)
New Revision: 84913
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
translation in progress08
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po 2009-03-02 04:57:34 UTC (rev 84912)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po 2009-03-02 05:52:08 UTC (rev 84913)
@@ -8,7 +8,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-26 16:17+1000\n"
+"PO-Revision-Date: 2009-03-02 15:50+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -1382,7 +1382,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:419
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The failure detection protocols are used to detect failed nodes. Once a "
"failed node is detected, a suspect verification phase can occur after which, "
@@ -1392,11 +1392,9 @@
"MBean <literal>Config</literal> element."
msgstr ""
"Los protocolos de detección de fallos se utilizan para detectar nodos con "
-"fallos. Una vez se detecta un nodo con fallos, el clúster actualiza su punto "
-"de vista de modo que el balanceador de carga y los interceptores de cliente "
+"fallos. Una vez se detecta un nodo con fallos, puede tener lugar una fase de verificación después de la cual si el nodo todavía se considera como muerto entonces el clúster actualiza su vista de modo que el balanceador de carga y los interceptores de cliente "
"sepan como evitar el nodo muerto. Los protocolos de detección de fallos son "
-"configurados como sub-elementos en el elemento <literal>Config</literal> del "
-"MBean JGroups."
+"configurados como sub-elementos en el MBean JGroups del elemento <literal>Config</literal>."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:425
@@ -1406,7 +1404,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:426
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"FD is a failure detection protocol based on heartbeat messages. This "
"protocol requires each node to periodically send are-you-alive messages to "
@@ -1416,12 +1414,11 @@
"node is still considered dead, updates the cluster's view. Here is an "
"example FD configuration."
msgstr ""
-"El protocolo de descubrimiento FD necesita que cada nodo envíe "
-"periodicamente mensajes are you alive a su vecino. Si el vecino falla en "
-"responder, el nodo que hizo la llamada envía un mensaje de SUSPECT al "
-"clúster. El coodinador actual del grupo verifica dos veces que el nodo "
+"FD es un protocolo de detección de fallos basado en mensajes de latidos. Este protocolo requiere que cada nodo envíe "
+"periodicamente mensajes are you alive a su vecino. Si el vecino no responde, el nodo que hizo la llamada envía un mensaje de SUSPECT al "
+"clúster. El coodinador actual del grupo puede opcionalmente verificar dos veces que el nodo "
"sospechoso si esté de hecho muerto y actualiza el punto de vista del "
-"clúster. Este es un ejemplo de la configuración FD:"
+"clúster. Este es un ejemplo de la configuración de FD:"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:430
@@ -1473,7 +1470,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:444
-#, fuzzy, no-c-format
+#, no-c-format
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 "
@@ -1483,9 +1480,9 @@
"behaivour within JBoss Application Server."
msgstr ""
"<emphasis role=\"bold\">shun</emphasis> especifica si un nodo con fallos "
-"será rechazado. Una vez rechazado, el nodo será explusado del clúster "
+"será rechazado. Una vez rechazado, el nodo será expulsado del clúster "
"inclusive si regresa despúes. El nodo rechazado tendría que re-agruparse al "
-"clúster por medio del proceso de descubrimiento (discovery process)."
+"clúster por medio del proceso de descubrimiento. JGroups permite configurarlo de manera que el rechazo conlleva a reagrupaciones automáticas y transferencias de estado, lo cual es el comportamiento predeterminado dentro del servidor de aplicaciones de JBoss. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:450
@@ -1519,6 +1516,8 @@
"You can just declare an empty <literal>FD_SOCK</literal> element in "
"JGroups's <literal>Config</literal> element."
msgstr ""
+"FD_SOCK es un protocolo de detección de fallos basado en un anillo de sockets TCP creados entre miembros de grupos. Cada miembro en un grupo se conecta a su vecino (el último miembro se conecta al primero) por lo tanto forma un anillo. Se sospecha del miembro B cuando su vecino A detecta el socket TCP cerrado de manera abnormal "
+"(presumiblemente debido a que el nodo B se colgó). Sin embargo, si un miembro B está a punto de irse, le deja saber a su vecino A de manera que no se convierte en sospechoso. La configuración más simple de FD_SOCK no toma ningun atributo. Simplemente puede declarar un elemento <literal>FD_SOCK</literal> vacío en el elemento <literal>Config</literal> de JGroups."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:464
@@ -1538,17 +1537,15 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:469
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface to "
"which the server socket should bind to. If -Djgroups.bind_address system "
"property is defined, XML value will be ignore. This behaivour can be "
"reversed setting -Djgroups.ignore.bind_addr=true system property."
msgstr ""
-"<emphasis role=\"bold\">srv_sock_bind_addr</emphasis> especifica la interfaz "
-"a la cual se debe vincular el socket del servidor. Si se omite, se utiliza "
-"la propiedad <literal>-D bind.address</literal> de la línea de comando de "
-"iniciación del servidor."
+"<emphasis role=\"bold\">bind_addr</emphasis> especifica la interfaz "
+"a la cual se debe vincular el socket del servidor. Si se define la propiedad del sistema -Djgroups.bind_address entonces se ignorará el valor XML. Este comportamiento se puede reversar configurando la propiedad del sistema -Djgroups.ignore.bind_addr=true. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:477
@@ -1565,7 +1562,7 @@
"the cluster. The suspected member is dropped from the cluster group if "
"confirmed to be dead. The aim of this protocol is to minimize false "
"suspicions. Here's an example."
-msgstr ""
+msgstr "Este protocolo verifica si un miembros sospechoso está realmente muerto realizando ping en ese miebro una vez más. Esta verificación la realiza el coordinador del clúster. Si se confirma que está muerto entonces el miembro sospechoso se borra del grupo del clúster. El objetivo de este protocolo es el minimizar falsas sospechas. Este es un ejemplo: "
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:482
@@ -1593,7 +1590,7 @@
msgid ""
"timeout specifies how long to wait for a response from the suspected member "
"before considering it dead."
-msgstr ""
+msgstr "El tiempo de espera especifica cuánto tiempo debe esperar por una respuesta del miembro sospechoso antes de conisderarlo como muerto. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:500
@@ -1608,7 +1605,7 @@
"FD and FD_SOCK, each taken individually, do not provide a solid failure "
"detection layer. Let's look at the the differences between these failure "
"detection protocols to understand how they complement each other:"
-msgstr ""
+msgstr "FD y FD_SOCK, cada uno tomado individualmente, no proporcionan una capa sólida de detección de fallos. Vamos a ver las diferencias entre estos protocolos de detección de fallos para comprender la manera en que se complementan el uno al otro:"
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:505
@@ -1620,13 +1617,13 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:510
#, no-c-format
msgid "An overloaded machine might be slow in sending are-you-alive responses."
-msgstr ""
+msgstr "Una máquina sobrecargada puede ser lenta al mandar respuestas are-you-alive. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:515
#, no-c-format
msgid "A member will be suspected when suspended in a debugger/profiler."
-msgstr ""
+msgstr "Un miembro será sospechoso cuando esté suspendido en un depurador/perfilador. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:520
@@ -1634,13 +1631,13 @@
msgid ""
"Low timeouts lead to higher probability of false suspicions and higher "
"network traffic."
-msgstr ""
+msgstr "Tiempos de espera bajos conllevan a una mayor probabilidad de falsas sospechas y mayor tráfico de red. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:525
#, no-c-format
msgid "High timeouts will not detect and remove crashed members for some time."
-msgstr ""
+msgstr "Tiempos de espera altos no detectarán ni eliminarán miembros colgados por un buen tiempo. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:532
@@ -1654,25 +1651,25 @@
msgid ""
"Suspended in a debugger is no problem because the TCP connection is still "
"open."
-msgstr ""
+msgstr "Suspendido en un depurador no es problema ya que la conexión TCP aún está abierta. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:543
#, no-c-format
msgid "High load no problem either for the same reason."
-msgstr ""
+msgstr "Alta carga tampoco es un problema por la misma razón. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:548
#, no-c-format
msgid "Members will only be suspected when TCP connection breaks"
-msgstr ""
+msgstr "Los miembros sólo serán sospechosos cuando la conexión TCP se rompe"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:557
#, no-c-format
msgid "So hung members will not be detected."
-msgstr ""
+msgstr "Así que los miembros colgados no se detectarán. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:562
@@ -1681,7 +1678,7 @@
"Also, a crashed switch will not be detected until the connection runs into "
"the TCP timeout (between 2-20 minutes, depending on TCP/IP stack "
"implementation)."
-msgstr ""
+msgstr "Un switch colgado tampoco será detectado hasta que la conexión se encuentre con el tiempo de expiración TCP (entre 2-20 minutos, dependiendo de la implementación de la pila TCP/IP). "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:569
@@ -1689,7 +1686,7 @@
msgid ""
"The aim of a failure detection layer is to report real failures and "
"therefore avoid false suspicions. There are two solutions:"
-msgstr ""
+msgstr "El propósito de una capa de detección de fallos es el reportar fallas reales y por lo tanto evitar falsas sospechas. Hay dos soluciones: "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:574
@@ -1705,6 +1702,8 @@
"This can only be done for the entire kernel in most operating systems, so if "
"this is lowered to 15 minutes, this will affect all TCP sockets."
msgstr ""
+"Por defecto, JGroups configura el socket FD_SOCK con KEEP_ALIVE, lo cual significa que TCP envía un latido en el socket en el que no se ha recibido tráfico en 2 horas. Si un host se colgó (o un switch intermedio o un enrutador se colgaron) sin cerrar apropiadamente la conexión TCP entonces detectariamos esto después de dos horas (y unos pocos minutos). Esto es mejor que no cerrar nunca la conexión (si KEEP_ALIVE está apagado), pero puede que no sea de mucha ayuda. "
+"Así que la primera solución sería el disminuir el valor del tiempo de expiración para KEEP_ALIVE. Esto solo se puede lograr para el kernel entero en la mayoría de los sistemas operativos así que si esto se disminuye a 15 minutos, esto afectará a todos los sockets TCP."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:579
@@ -1716,7 +1715,7 @@
"message if the socket was closed abnormally. However, in the case of a "
"crashed switch or host, FD will make sure the socket is eventually closed "
"and the suspect message generated. Example:"
-msgstr ""
+msgstr "La segunda solución es el combinar FD_SOCK y FD; el tiempo de expiración en FD se puede configurar de manera que sea menor que el tiempo de expiración TCP y esto se puede establecer de manera individual para cada proceso. FD_SOCK generará un mensaje de sospecha si el socket se cerró abnormalmente. Sin embargo, en el caso de un host o switch colgados, FD se asegurará de que el socket se cierre eventualmente y de que se genere el mensaje de sospecha. Por ejemplo: "
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:584
@@ -1743,7 +1742,7 @@
"seconds. Note that with this example, if you have your system stopped in a "
"breakpoint in the debugger, the node you're debugging will be suspected "
"after ca 50 seconds."
-msgstr ""
+msgstr "Este sospecha de un miembro cuando el socket del vecino se ha cerrado de manera abnormal (por ejemplo, el proceso se colgó ya que el sistema operativo cerró todos los sockets). Sin embargo, si un host o un swicth se cuelgan entonces los sockets no se cerrarán y por lo tanto como segunda línea de defensa, FD sospechará de un vecino después de 50 segundos. Observe que con este ejemplo, si tiene su sistema detenido en un punto crucial en el depurador entonces el nodo que está depurando será sospechoso después de 50 segundos. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:589
@@ -1753,6 +1752,8 @@
"for this reason, such technique is used accross JGroups configurations "
"included within JBoss Application Server."
msgstr ""
+"Una combinación de FD y FD_SOCK proporciona una capa sólida de detección de fallos y por esta razón dicha técnica se utiliza através de configuraciones JGroups "
+"incluidas dentro del servidor de aplicaciones de JBoss."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:598
@@ -1762,7 +1763,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:599
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"Reliable delivery protocols within the JGroups stack ensure that data "
"pockets are actually delivered in the right order (FIFO) to the destination "
@@ -1771,8 +1772,8 @@
"the message until the acknowledgment is received from the receiver. In the "
"NAK mode, the receiver requests retransmission when it discovers a gap."
msgstr ""
-"Los protocolos de entrega confiables en la pila JGroups se aseguran de que "
-"los pockets de datos de hecho son entregados en el orden adecuado (FIFO) al "
+"Los protocolos de entrega confiables dentro de la pila JGroups se aseguran de que "
+"los pockets de datos de hecho sean entregados en el orden adecuado (FIFO) al "
"nodo de destino. La base para la entrega de mensajes de manera confiable son "
"los reconocimientos de entrega positivos y negativos (ACK y NAK). En el modo "
"ACK, el remitente lo vuelve a enviar hasta que se recibe el reconocimiento "
@@ -1787,7 +1788,7 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:607
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The UNICAST protocol is used for unicast messages. It uses ACK. It is "
"configured as a sub-element under the JGroups Config element. If the JGroups "
@@ -1796,8 +1797,7 @@
"example configuration for the <literal>UNICAST</literal> protocol."
msgstr ""
"El protocolo UNICAST se utiliza para mensajes unicast y utiliza ACK. Está "
-"configurado como un sub-elemento bajo el elemento <literal>Config</literal> "
-"del JGroups. Este es un ejemplo de la configuración para el protoclo "
+"configurado como un sub-elemento bajo el elemento Config de JGroups. Si la pila JGroups está configurada con el protocolo de transporte TCP, UNICAST no es necesario ya que TCP garantiza entrega FIFO de mensajes unicast. Esta es una configuración de ejemplo para el protoclo "
"<literal>UNICAST</literal>."
#. Tag: programlisting
@@ -1943,13 +1943,11 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:661
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">gc_lag specifies</emphasis> the number of messages "
"garbage collection lags behind."
-msgstr ""
-"<emphasis role=\"bold\">className</emphasis>: El nombre de la clase que "
-"brinda la implementación del servicio."
+msgstr "<emphasis role=\"bold\">gc_lag specifies</emphasis> el número de mensajes que el recolector de basura deja atrás."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:672
@@ -2086,6 +2084,8 @@
"together at the same time, only sending out 1 new view / bundle. This is is "
"more efficient than handling each request separately."
msgstr ""
+"<emphasis role=\"bold\">view_bundling</emphasis> especifica si múltiples peticiones "
+"JOIN o LEAVE que llegan al mismo tiempo se enlazan y se manejan al mismo tiempo solo enviando una nueva vista/paquete. Esto es más eficiente que el manejar cada petición de manera separada."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:720
@@ -2191,6 +2191,8 @@
"receivers whose credits are currently below 0, until it receives credits "
"from all members whose credits are below 0."
msgstr ""
+"<emphasis role=\"bold\">min_block_time</emphasis> especifica el tiempo máximo (en "
+"milisegundos) que un remitente bloquea. Si un remitente bloquea y no se han recibido créditos después de 5 segundos entonces envía una petición de crédito de manera explícita a los recibidores cuyos créditos actualmente son menores que 0, hasta que recibe créditos de todos los miembros cuyos créditos son menores que 0."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:755
@@ -2213,13 +2215,13 @@
"receiver can keep up with. TCP flow control only takes into account "
"individual node communications and has not a notion of who's the slowest in "
"the group, which is why FC is required."
-msgstr ""
+msgstr "Las aplicaciones que utilizan llamadas sincrónicas RPC de grupo principalmente no requieren protocolo FC en su pila de protocolo JGroups ya que la comunicación sincrónica, en donde el hilo que realiza la llamada bloquea en espera de las respuestas de todos los miembros del grupo, disminuye la tasa promedio de llamadas. Aunque TCP brinda control de flujo por sí mismo, FC todavía se requiere en TCP basado en pilas JGroups debido a la comunicación de grupo, en donde esencialmente tenemos que enviar mensajes de grupo en la velocidad más alta que el recibidor más lento pueda manejar. El control de flujo TCP solo toma en cuenta comunicaciones de nodos individuales y no tiene noción de quién es el más despacioso en el grupo, razón por la cual se requiere FC. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:762
#, no-c-format
msgid "Why is FC needed on top of TCP ? TCP has its own flow control !"
-msgstr ""
+msgstr "¿Por qué se necesita FC encima de TCP? ¡TCP tiene su propio control de flujo! "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:763
@@ -2236,6 +2238,11 @@
"1M messages. (BTW: this is also the reason why we need NAKACK, although TCP "
"does its own retransmission)."
msgstr ""
+"La razón es comunicación de grupo, en donde esencialmente tenemos que enviar mensajes de grupo en la velocidad más alta que el recibidor más lento puede manejar. Digamos que tenemos un clúster {A,B,C,D}. D es lento (tal vez sobrecargado), el resto es "
+"rápido. Cuando A envía un mensaje de grupo, establece conexiones TCP A-A "
+"(conceptualmente), A-B, A-C y A-D (si todavía no existen). Así que digamos que A "
+"envía 100 millones de mensajes al clúster. Debido al control de flujo de TCP solo aplica a A-B, A-C y A-D, pero no a A-{B,C,D}, en donde {B,C,D} es el "
+"grupo, es posible que A, B y C reciban los 100M, pero D solo recibió 1M de mensajes, (esta también es la razón por la cual necesitamos NAKACK aunque TCP realiza su propia retransmisión)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:767
@@ -2248,7 +2255,7 @@
"done by the STABLE protocol, which can be configured to run the stability "
"protocol round time based (e.g. every 50s) or size based (whenever 400K data "
"has been received)."
-msgstr ""
+msgstr "Ahora JGroups tiene que poner en buffer todos los mensajes en la memoria para que en caso de que el remitente original S muera y un nodo pida la retransmisión de un mensaje de S. ya que todos los miembros ponen en buffer todos los mensajes que recibieron, necesitan depurar los mensajes estables (= los mensajes vistos por todo el mundo) de vez en cuando. Esto lo hace el protocolo STABLE, el cual se puede configurar para ejecutar el protocolo de estabilidad con base en rondas (por ejemplo, cada 50s) o con base en tamaño (cuando se hayan recibido 400K)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:770
@@ -2261,6 +2268,8 @@
"in the above case that this is still much faster for A-B and A-C than for A-"
"D."
msgstr ""
+"En el caso anterior, el nodo despacioso D evitará que el grupo depuer mensajes por encima de 1M así que todo miembro pondrá en buffer ¡99 mensajes! En la mayoría de los casos esto conlleva a excepciones OOM. Observe que - aunque el protocolo de la ventana en TCP hará que las escrituras se bloqueen si la ventana se encuentra llena - asuminos en el caso anterior que esto será mucho más rápido para A-B y A-C que para A-"
+"D."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:773
@@ -2268,13 +2277,13 @@
msgid ""
"So, in summary, we need to send messages at a rate the slowest receiver (D) "
"can handle."
-msgstr ""
+msgstr "Así que en resumen necesitamos enviar mensajes con una velocidad que el recibidor más lento (D) pueda manejar. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:779
#, no-c-format
msgid "So do I always need FC?"
-msgstr ""
+msgstr "¿Siempre necesito FC?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:780
@@ -2284,7 +2293,7 @@
"the example above, if there was something about the application that would "
"naturally cause A to slow down its rate of sending because D wasn't keeping "
"up, then FC would not be needed."
-msgstr ""
+msgstr "Esto depende de la manera en que la aplicación utiliza el canal JGroups. Con referencia al ejemplo anterior, si hubiese algo con relación a la aplicación que causaría naturalmente que A disminuyera su velocidad de envío ya que D no alcanzaba entonces FC no se necesitaría. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:783
@@ -2296,7 +2305,7 @@
"members of the group. In that kind of application, the threads on A that are "
"making calls would block waiting for responses from D, thus naturally "
"slowing the overall rate of calls."
-msgstr ""
+msgstr "Un buen ejemplo de tal aplicación es la que realiza llamadas sincrónicas RPC de grupo (usualmente utilizando un JGroups RpcDispatcher). Por sincrónico lo que queremos decir es que el hilo que realiza la llamada bloquea en espera de respuestas de todos los miembros del grupo. En esa clase de aplicación, los hilos en A que está realizando las llamadas bloquearían en espera por respuetas de D y por lo tanto naturalmente disminuyendo la velocidad general de las llamadas. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:786
@@ -2307,6 +2316,8 @@
"used for a cache configured for REPL_SYNC, we recommend you remove FC from "
"its protocol stack."
msgstr ""
+"Un clúster JBoss Cache configurado para REPL_SYNC es un buen ejemplo de una "
+"aplicación que realiza llamadas sincrónicas RPC de grupo. Si un canal solo se utiliza para un caché configurado para REPL_SYNC, le recomendamos que elimine FC de su pila de protocolo."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:789
@@ -2316,7 +2327,7 @@
"a TCP-based protocol stack is unnecessary. There is no group beyond the "
"single peer-to-peer relationship, and TCP's internal flow control will "
"handle that just fine."
-msgstr ""
+msgstr "Por supuesto si su clúster solo consiste de dos nodos, no es necesario incluir FC en una pila de protocolo con base en TCP. No hay grupo más allá de solo una relación compañero-a-compañero y el control de flujo interno de TCP manejará esto bien. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:792
@@ -2329,7 +2340,7 @@
"related to data gravitation that go to all members, but in a properly "
"engineered buddy replication use case these should be infrequent. But if you "
"remove FC be sure to load test your application.)"
-msgstr ""
+msgstr "Otro caso en donde puede que no sea necesario FC es para un canal utilizado por un caché de JBoss configurado para replicación de compañeros y un solo companero. Tal canal se comportará en muchos aspectos como un clúster de dos nodos, en donde los mensajes solo se intercambian con otro nodo, el compañero (puede que hayan otros mensajes relacionados con la gravitación de datos que van a todos los miembros pero en un caso de replicación de compañeros apropiadamente diseñado estos deben ser poco frecuentes. Pero si elimina FC asegúrese de probar su aplicación). "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:802
@@ -2345,7 +2356,7 @@
"the receiver's side. It works for both unicast and multicast messages. It is "
"configured in the FRAG2 sub-element under the JGroups Config element. Here "
"is an example configuration."
-msgstr ""
+msgstr "Este protocolo frgamenta mensajes más grandes de cierto tamaño. Desfragmenta del lado del recibidor. Funciona para mensajes unicast y multicast. Está configurado en el sub-elemento FRAG2 bajo el elemento Config de JGroups. Esta es una configuración de ejemplo: "
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:806
@@ -2369,14 +2380,13 @@
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:813
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in "
"bytes. Messages larger than that are fragmented."
msgstr ""
-"<emphasis role=\"bold\">max_credits</emphasis> especifica el número máximo "
-"de créditos (en bytes). Este valor debe ser más pequeño que el tamaño del "
-"JVM heap."
+"<emphasis role=\"bold\">frag_size</emphasis> especifica el tamaño máximo de fragmento en "
+"bytes. Los mensajes son más grandes que los fragmentados."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:817
@@ -2386,7 +2396,7 @@
"protocol is still needed if FC is used. The reason for this is that if you "
"send a message larger than FC.max_bytes, FC protocol would block. So, "
"frag_size within FRAG2 needs to be set to always be less than FC.max_bytes."
-msgstr ""
+msgstr "El protocolo TCP ya proporciona fragmentación pero todavía se necesita un protocolo JGroups de fragmentación en caso de que se utilice FC. La razón para esto es que si envía un mensaje más grande que FC.max_bytes, el protocolo FC lo bloquearía. Así que frag_size dentro de FRAG2 necesita ser configurado para que siempre sea menor que FC.max_bytes."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:826
@@ -2501,7 +2511,7 @@
"<emphasis role=\"bold\">stability_delay</emphasis> specifies delay before we "
"send STABILITY msg (give others a change to send first). If used together "
"with max_bytes, this attribute should be set to a small number."
-msgstr ""
+msgstr "<emphasis role=\"bold\">stability_delay</emphasis> especifica el retraso antes de enviar un mensaje STABILITY (dándole la oportunidad a otros para enviarlo primero). Si se utiliza junto con max_bytes, este atributo se debe configurar con un número pequeño."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:859
@@ -2592,13 +2602,13 @@
"even though shunning is disabled. Alternatively use MPING, which is commonly "
"used with TCP to provide multicast member discovery capabilities, instead of "
"TCPPING to avoid having to specify all the nodes."
-msgstr ""
+msgstr "Los estados del clúster no se combinan en un merger. Esto lo tiene que hacer la aplicación. Si se utiliza <literal>MERGE2</literal> junto con TCPPING, el atributo <literal>initial_hosts</literal> debe contener todos los nodos que potencialmente se podrían combinar para que el proceso de combinación funcione apropiadamente. De otra manera este proceso no combinaría todos los nodos aunque el rechazo está deshabilitado. Opcionalmente utilice MPING, el cual se utiliza comúnmente con TCP para brindar capacidades de descubrimiento de miembros multicast en lugar de TCPPING para evitar el tener que especificar todos los nodos. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:892
#, no-c-format
msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
+msgstr "Vinculación de canales JGroups a una interfaz en particular"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:893
@@ -2607,7 +2617,7 @@
"In the Transport Protocols section above, we briefly touched on how the "
"interface to which JGroups will bind sockets is configured. Let's get into "
"this topic in more depth:"
-msgstr ""
+msgstr "En la sección anterior sobre protocolos de transporte mencionamos brevemente la manera en que se configura la interfaz a la cual JGroups vinculará sockets. Vamos a abordar este tema más profundamente: "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:896
@@ -2620,7 +2630,7 @@
"property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) "
"switch, the AS will set <literal>jgroups.bind_addr</literal> to the "
"specified value."
-msgstr ""
+msgstr "Primero es importante comprender que el valor establecido en cualquier elemento bind_addr en un archivo de configuración XML será ignorado por JGroups si encuentra que la propiedad del sistema jgroups.bind_addr (o un nombre previo para lo mismo, <literal>bind.address</literal>) ha sido configurada. La propiedad del sistema triunfa sobre el XML. Si JBoss AS se inicia con la opción -b (también conocido como --host), el AS configurará <literal>jgroups.bind_addr</literal> con el valor especificado. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:899
@@ -2631,6 +2641,8 @@
"users are going to be setting -b and thus jgroups.bind_addr is going to be "
"set and any XML setting will be ignored."
msgstr ""
+"Desde AS 4.2.0, por razones de seguridad el AS vinculará la mayoría de los servicios "
+"a un localhost si no se configura -b. El efecto de esto es que en la mayoría de los casos los usuarios van a configurar -b y por lo tanto jgroups.bind_addr va a se establecida y cualquier configuración de XML se ignorará."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:902
@@ -2638,13 +2650,13 @@
msgid ""
"So, what are <emphasis>best practices</emphasis> for managing how JGroups "
"binds to interfaces?"
-msgstr ""
+msgstr "¿Cuáles son las<emphasis>mejores técnicas</emphasis> para administrar la manera en que JGroups vincula a interfaces?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:907
#, no-c-format
msgid "Binding JGroups to the same interface as other services. Simple, just use -b:"
-msgstr ""
+msgstr "Vinculación de JGroups a la misma interfaz que otros servicios. Simplemente utilice -b:"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:909
@@ -2662,6 +2674,9 @@
"property overrides the -b value. This is a common usage pattern; put client "
"traffic on one network, with intra-cluster traffic on another."
msgstr ""
+"Vinculación de servicios (por ejemplo, JBoss Web) a una interfaz, pero utilice una diferente para JGroups: <screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen> Especificamente configurando la propiedad del sistema "
+"sobreescribe el valor -b. Este es un patrón común de uso; pone el tráfico del cliente e una red y el tráfico intra-clúster en otra."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:921
@@ -2673,7 +2688,7 @@
"the machine's default interface. See the Transport Protocols section for how "
"to tell JGroups to receive or send on all interfaces, if that is what you "
"really want."
-msgstr ""
+msgstr "Vinculación de servicios (por ejemplo, JBoss Web) en todas las interfaces. Esto se puede hacer así: <screen>./run.sh -b 0.0.0.0 -c all</screen> Sin embargo el hacerlo así no hará que JGroups vincule a ¡todas las interfaces! En lugar , JGroups se vinculará a la interfaz predeterminada de la máquina. Consulte la sección sobre protocolos de transporte para ver como decirle a JGroups que reciba o envíe en todas las interfaces, si eso es lo que en realidad quiere."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:929
@@ -2684,6 +2699,8 @@
"bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
"system property overrides the -b value."
msgstr ""
+"Vinculación de servicios (por ejemplo, JBoss Web) a todas las interfaces, pero especifica la interfaz JGroups: <screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen> De nuevo, especificamente configurando ña propiedad del sistema sobreescribe el valor -b."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:937
@@ -2706,6 +2723,9 @@
"would need to edit the various XML configuration files to set the "
"<literal>bind_addr</literal> to the desired interfaces."
msgstr ""
+"Esta configuración le dice a JGroups que ignore la propiedad del sistema <literal>jgroups.bind_addr</"
+"literal> y en su lugar utilice lo que se especifica en el XML. Necesita modificar varios de los archivos de configuración XML para establecer el "
+"<literal>bind_addr</literal> con las interfaces deseadas."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:949
@@ -2722,7 +2742,7 @@
"replication, EJB3 SFSB replication and EJB3 entity replication) along with "
"the general purpose clustering service called HAPartition that underlies "
"most other JBossHA services."
-msgstr ""
+msgstr "Dentro de JBoss AS, hay un número de servicios que crean independientemente canales JGroups channels -- 3 servicios diferentes JBoss Cache (utilizados para replicación HttpSession, replicación EJB3 SFSB y replication de entidades EJB3) junto con el servicio de propósitos generales de clústering llamado HAPartition que subyace la mayoría de los servicios JBossHA."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:953
@@ -2733,7 +2753,7 @@
"for the same service opened on machines not meant to be part of the group. "
"Nodes improperly communicating with each other is one of the most common "
"issues users have with JBoss AS clustering."
-msgstr ""
+msgstr "Es crítico que estos canales solo se comuniquen con los compañeros pensados y no con los canales utilizados por otros servicios y no con canales para el mismo servicio abiertos en máquinas que no se suponen que sean parte del grupo. Uno de los problemas más comunes que se tiene con JBoss AS clustering es la comunicación entre nodos inapropiados."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:956
@@ -2743,7 +2763,7 @@
"multicast address, and multicast port, so isolating JGroups channels comes "
"down to ensuring different channels use different values for the group name, "
"multicast address and multicast port."
-msgstr ""
+msgstr "El nombre del grupo, la dirección multicast y el puerto multicast definen con quien se comunicará el canal JGroups así que el aislar los canales JGroups al final se trata de asegurarse de que diferentes canalaes utilicen diferentes valores para el nombre de grupo, la dirección y el puerto multicast. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:959
@@ -2752,7 +2772,7 @@
"To isolate JGroups channels for different services on the same set of AS "
"instances from each other, you MUST change the group name and the multicast "
"port. In other words, each channel must have its own set of values."
-msgstr ""
+msgstr "Para aislar los canales JGroups para diferentes servicios en el mismo grupo de instancias AS TIENE que cambiar el nombre del grupo y el puerto multicast. En otras palabras, cada canal debe tener su propio grupo de valores."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:962
@@ -2764,6 +2784,8 @@
"Cache channels. They should use a different group name and multicast port. "
"They can use the same multicast address, although they don't need to."
msgstr ""
+"Por ejemplo digamos que tenemos un clúster de producción de tres máquinas, cada una de las cuales tienen una HAPartition desplegada junto con un JBoss Cache utilizado para clústers de sesiones web. Los canales HAPartition no se deben comunicar con los canales JBoss "
+"Cache. Deben utilizar un nombre de grupo diferente y puerto multicast. Pueden utilizar la misma dirección multicast aunque no lo necesitan."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:965
@@ -2772,7 +2794,7 @@
"To isolate JGroups channels for the same service from other instances of the "
"service on the network, you MUST change ALL three values. Each channel must "
"have its own group name, multicast address, and multicast port."
-msgstr ""
+msgstr "Para aislar canales JGroups para el mismo servicio de otras instancias del servicio en la red, TIENE que cambiar los TRES valores. Cada canal debe tener su propio nombre de grupo, dirección multicast y puerto multicast. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:968
@@ -2783,7 +2805,7 @@
"of 3 machines, which also has an HAPartition deployed. The HAPartition group "
"name, multicast address, and multicast port for the production machines must "
"be different from those used on the QA machines."
-msgstr ""
+msgstr "Por ejemplo digamos que tenemos un clúster de producción de tres máquinas, cada una de las cuales tienen una HAPartition desplegada. En la misma red también hay un clúster QA de tres máquinas, las cuales también tienen una HAPartition implementada. El nombre de grupo de HAPartition, la dirección multicast y el puerto multicast para las máquinas de producción deben ser diferentes de aquellos utilizados en las máquinas QA. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:974
@@ -2801,7 +2823,7 @@
"configured in the deploy/cluster-service.xml file, this is configured via a "
"PartitionName attribute. For JBoss Cache services, the name of the attribute "
"is ClusterName."
-msgstr ""
+msgstr "El nombre de grupo para un canal JGroups se configura por medio del servicio que inicia el canal. Desafortunadamente servicios diferentes utilizan diferentes nombres de atributos para configurar esto. Para HAPartition y los servicios relacionados configurados en el archivo deploy/cluster-service.xml, esto se configura por medio de un atributo PartitionName. Para los servicios JBoss Cache, el nombre del atributo es ClusterName."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:978
@@ -2815,6 +2837,9 @@
"configuration of the group name in all the standard clustering configuration "
"files. For example,"
msgstr ""
+"Desde JBoss AS 4.0.4, para la HAPartition y todos los servicios estándar de JBoss "
+"Cache, le facilitamos crear nombres únicos de grupos simplemente utilizando la opción -g (conocida como –partition) al iniciar JBoss: <screen>./"
+"run.sh -g QAPartition -b 192.168.1.100 -c all</screen> Esta opción configura la propiedad del sistema jboss.partition.name, la cual se utiliza como un componente en la configuración del nombre del grupo en todos los archivos de configuración estándares de clústers. Por ejemplo:"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:982
@@ -2843,6 +2868,9 @@
"udpGroup system property, which you can see referenced in all of the "
"standard protocol stack configs in JBoss AS:"
msgstr ""
+"Se puede utilizar la opción -u (también conocida como --udp) para controlar la dirección multicast utilizada por los canales JGroups abiertos por todos los servicios AS estándares. <screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b "
+"192.168.1.100 -c all]]></screen> Esta opción configura la propiedad del sistema jboss.partition."
+"udpGroup, la cual puede ver referenciada en todas las configuraciones estándares de la pila de protocolos en JBoss AS:"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:995
@@ -2886,7 +2914,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1001
#, no-c-format
msgid "Why isn't it sufficient to change the group name?"
-msgstr ""
+msgstr "¿Por qué no es suficiente el cambiar el nombre del grupo?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1002
@@ -2902,7 +2930,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1006
#, no-c-format
msgid "Why do I need to change the multicast port if I change the address?"
-msgstr ""
+msgstr "¿Por qué necesito cambiar el puerto multicast si cambio la dirección?"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1007
@@ -2992,7 +3020,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1036
#, no-c-format
msgid "Causes of missing heartbeats in FD"
-msgstr ""
+msgstr "Causas de pérdida de latidos en FD"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:1037
More information about the jboss-cvs-commits
mailing list