[jboss-cvs] JBossAS SVN: r84150 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Feb 13 00:44:00 EST 2009
Author: gcintra
Date: 2009-02-13 00:44:00 -0500 (Fri, 13 Feb 2009)
New Revision: 84150
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
100% translated, now proofreading
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_JBoss_Cache_JGroups.po 2009-02-13 05:32:51 UTC (rev 84149)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_JBoss_Cache_JGroups.po 2009-02-13 05:44:00 UTC (rev 84150)
@@ -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-10 15:40+1000\n"
+"PO-Revision-Date: 2009-02-13 15:43+1000\n"
"Last-Translator: Glaucia Cintra <gcintra at redhat.com>\n"
"Language-Team: Portuguese <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -529,7 +529,7 @@
"handler is a separate thread taking care of de-serialization, receiver thread"
"(s) simply put packet in queue and return immediately. Setting this to true "
"adds one more thread. The default is <literal>true</literal>."
-msgstr ""
+msgstr "<emphasis role=\"bold\">use_incoming_packet_handler</emphasis> especifica se deve-se utilizar um segmento separado para processar as mensagens de entrada. Às vezes os destinatários estão sobrecarregados (eles precisam lidar com a desserialização, etc.). O manuseador do pacote é um segmento separado que cuida da desserialização, o segmento do destinatário simplesmente coloca o pacote na fila e o retorna imediatamente. Ao configurar isto para verdadeiro, adiciona-se um segmento. O padrão é <literal>true</literal>."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:118
@@ -694,6 +694,8 @@
"use MPING or TCPGOSSIP as discovery protocol because <literal>TCCPING</"
"literal> requires listing the nodes and their corresponding ports."
msgstr ""
+"<emphasis role=\"bold\">start_port, end_port</emphasis> define a classe de portas TCP que o servidor deve-se vincular. O soquete do servidor é vinculado à primeira porta disponível a partir da <literal>start_port</literal>. Caso não haja nenhuma porta disponível (ex.: por causa do firewall) antes da <literal>end_port</literal>, o servidor joga uma exceção. Caso nenhuma <literal>end_port</literal> seja fornecida ou <literal>end_port < start_port</literal> então não haverá limite mais alto na classe da porta. Se <literal>start_port == end_port</literal>, então forçamos o JGroup para usar a porta fornecida (o start falha se a porta não estiver disponível). O padrão é 7800. Caso seja estabelecido para 0, então o sistema operacional escolherá uma porta. Por favor, lembre-se que ao configurá-lo para 0, ele funcionará somente se usarmos o MPING ou TCPGOSSIP como protocolo de descoberta, pois <literal>TCCPING</"
+"literal> requer uma listagem dos nós e suas portas correspondentes. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:182
@@ -751,7 +753,7 @@
"millis for a socket creation. When doing the initial discovery, and a peer "
"hangs, don't wait forever but go on after the timeout to ping other members. "
"Reduces chances of *not* finding any members at all. The default is 2000."
-msgstr ""
+msgstr "<emphasis role=\"bold\">sock_conn_timeout</emphasis> especifica o tempo máximo em millis para a criação do soquete. Ao fazer uma descoberta inicial, e um parceiro trava, não espere por muito tempo, vá atrás do timeout para chamar outros membros utilizando 'ping'. Isto reduz chances de *não* encontrar ao menos um membro. O padrão é 2000."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:203
@@ -780,7 +782,7 @@
"node inside the firewall, but only on its external address. Without setting "
"the external_addr, the node behind the firewall will broadcast its private "
"address to the other nodes which will not be able to route to it."
-msgstr ""
+msgstr "<emphasis role=\"bold\">external_addr</emphasis> especifica o endereço IP externo para transmitir à outros membros do grupo ( caso seja diferente do endereço local). Isto é útil quando você precisa usar (Network Address Translation) NAT, ex.: um nó em uma rede privada, atrás de um firewall, mas você pode roteá-lo somente através de um endereço visível externo, o qual é diferente de um endereço local que ele é vinculado. Portanto, o nó pode ser configurado para transmitir seus endereços externos, e ainda ser capaz de vincular ao endereço local. Isto evita a necessidade de usar o protocolo TUNNEL, (e assim um requerimento para um roteador gossip central) pois os nós fora do firewall ainda podem rotear para o nó dentro do firewall, mas somente em seu endereço externo. Sem o endereço externo, o nó atrás do firewall irá transmitir seu endereço privado à outros nós, os quais não poderão rotear para ele."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:209
@@ -802,7 +804,7 @@
"(by setting <literal>enable_bundling</literal> to false). Nagling is "
"disabled by setting <literal>tcp_nodelay</literal> to true. The default is "
"false."
-msgstr ""
+msgstr "<emphasis role=\"bold\">tcp_nodelay</emphasis> especifica TCP_NODELAY. O TCP utiliza o algorítmo de nagle nas mensagens, ou seja, mensagens menores são agrupadas às maiores. Se quisermos invocar uma chamada de método cluster síncrono, precisamos desabilitar o algorítmo de Nagle, além de desabilitar o agrupamento de mensagens (ao configurar <literal>enable_bundling</literal> para falso). O algorítmo de Nagle é desativado ao configurar o <literal>tcp_nodelay</literal> para verdadeiro. O padrão é falso. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:220
@@ -945,13 +947,13 @@
"joiner determines the coordinator from the responses, and sends a JOIN "
"request to it (handled by). If nobody responds, we assume we are the first "
"member of a group."
-msgstr ""
+msgstr "O PING é um protocolo de descoberta que funciona transmitindo as requisições do PING à um endereço de multicast IP ou conectando-o à um roteador gossip. Assim, o PING geralmente fica acima do UDP ou dos protocolos de transporte de TUNNEL. Cada nó responde com um pacote {C, A}, onde o C= endereço do coordenador e o A=endereço próprio. Após os milissegundos do timeout ou respostas do num_initial_members, a ligação determina o coordenador a partir das respostas, e envia uma requisição de JOIN para ele (manuseado por ele). Se ninguém responder, consideramos que somos o primeiro membro de um grupo."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:266
#, no-c-format
msgid "Here is an example PING configuration for IP multicast."
-msgstr ""
+msgstr "Aqui está um exemplo de configuração de PING para um multicast IP."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:270
@@ -969,7 +971,7 @@
#: Clustering_Guide_JBoss_Cache_JGroups.xml:271
#, no-c-format
msgid "Here is another example PING configuration for contacting a Gossip Router."
-msgstr ""
+msgstr "Aqui está outro exemplo de configuração do PING para contatar um Roteador Gossip."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:273
@@ -1216,7 +1218,7 @@
"connect to hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, "
"hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options "
"allows for multiple nodes on the same host to be pinged."
-msgstr ""
+msgstr "<emphasis role=\"bold\">port_range</emphasis> especifica o número de portas consecutivas a serem analisadas ao obter inscrição inicial, iniciando com a porta especificada no parâmetro de initial_hosts. Considerando os valores atuais do port_range e initial_hosts acima, a camada do TCPPING irá tentar se conectar ao hosta:2300, hosta:2301, hosta: 2302, hostb: 3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502. As opções de configuração permitem que nós múltiplos na mesma máquina sejam chamados."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:381
@@ -1235,7 +1237,7 @@
"when we want TCP as transport, but multicasting for discovery so we don't "
"have to define a static list of initial hosts in TCPPING or require external "
"Gossip Router."
-msgstr ""
+msgstr "MPING usa o multicast IP para descobrir a associação inicial. Ele pode ser usado com todos os transportes, mas geralmente ele é usado junto ao TCP. O TCP geralmente requer o TCPPING, o qual precisa listar todos os membros do grupo de forma explícita, mas o MPING não precisa deste requerimento. Geralmente ele é usado para quando queremos utilizar o TCP como transporte, mas o multicasting para descoberta, assim não precisamos definir uma lista estática de máquinas iniciais no TCPPING ou requerer Roteadores de Gossip externos. "
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:386
@@ -1439,7 +1441,7 @@
"suspected. The simplest FD_SOCK configuration does not take any attribute. "
"You can just declare an empty <literal>FD_SOCK</literal> element in "
"JGroups's <literal>Config</literal> element."
-msgstr ""
+msgstr "FD_SOCK é um protocolo de detecção de falha baseado em um anel de sockets de TCP, criado entre membros do grupo. Cada membro em um grupo, se conecta ao seu vizinho (último membro conecta-se ao primeiro), assim formando um anel. O Membro B é suspeito quando seu vizinho A detecta sockets de TCP fechados de forma incomum (provavelmente devido à uma falha do nó B). No entanto, se um membro B estiver saindo de forma sutil, ele avisa seu vizinho A, para que ele não se torne suspeito. A configuração mais simples do FD_SOCK não requer nenhum atributo. Você simplesmente declara um elemento <literal>FD_SOCK</literal> vazio no elemento <literal>Config</literal> do JGroup."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:464
@@ -1482,7 +1484,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 se um membro suspeito está realmente falho, chamando o membro com o ping mais uma vez. Esta verificação é realizada pelo coordenador do cluster. O membro suspeito é despejado de um grupo de cluster se confirmado que está falho. O objetivo deste protocolo é minimizar falsas suspeitas. Aqui está um exemplo:"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:482
@@ -1525,7 +1527,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 "O FD e FD_SOCK, não fornece uma camada de detecção de falha sólida. Vamos ver as diferenças entre estes protocolos de detecção de falhas para entender como eles se complementam."
#. Tag: emphasis
#: Clustering_Guide_JBoss_Cache_JGroups.xml:505
@@ -1598,7 +1600,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 "Também, uma opção travada não será detectada até que a conexão seja executada dentro do timeout do TCP (entre 2-20 minutos, dependendo da implementação da pilha de TCP/IP)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:569
@@ -1606,7 +1608,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 "O objetivo de uma camada de detecção de falha é reportar falhas reais e assim evitar falsas suspeitas. Existem duas soluções:"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:574
@@ -1621,7 +1623,7 @@
"So, the first solution would be to lower the timeout value for KEEP_ALIVE. "
"This can only be done for the entire kernel in most operating systems, so if "
"this is lowered to 15 minutes, this will affect all TCP sockets."
-msgstr ""
+msgstr "Por padrão, o JGroups configura o socket do FD_SOCK com o KEEP_ALIVE, o qual significa que o TCP envia uma pulsação em socket que não recebeu tráfego durante as últimas 2 horas. Se um host trava ( ou uma opção intermediária ou roteador travado) sem fechar a conexão do TCP adequadamente, nós o detectariamos após 2 horas (além de alguns minutos). Isto é claro muito melhor do que nunca fechar a conexão (se o KEEP_ALIVE estiver desligado), mas pode não ser de muita ajuda. Portanto, a primeira solução seria diminuir o valor do timeout para KEEP_ALIVE. Isto pode ser feito somente para o kernel inteiro na maioria dos sistemas operacionais, portanto se ele é diminuído para 15 minutos, isto afetará todos os sockets de TCP."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:579
@@ -1633,7 +1635,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 "A segunda solução é combinar o FD_SOCK e o FD. O timeout do FD pode ser estabelecido de forma que seja muito mais baixo do que o timeout do TCP, e isto pode ser configurado individualmente por processo. O FD_SOCK já irá gerar uma mensagem suspeita se o socket foi fechado de forma incomum. No entanto, no caso de uma opção de travamento ou host, o FD garantirá que o socket seja fechado por fim e a mensagem suspeita seja gerada. Exemplo:"
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:584
@@ -1660,7 +1662,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 suspeita de um membro quando o socket ao vizinho foi fechado de forma incomum (ex.: travamento de processo, pois o SO fecha todos os sockets). No entanto, se um host ou opção travar, os sockets não fecharão, portanto, como uma segunda linha de defesa, se você interromper seu sistema em um ponto de interrupção no depurador, o nós que você está depurando será suspeito após 50 segundos."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:589
@@ -1669,7 +1671,7 @@
"A combination of FD and FD_SOCK provides a solid failure detection layer and "
"for this reason, such technique is used accross JGroups configurations "
"included within JBoss Application Server."
-msgstr ""
+msgstr "Uma combinação do FD e FD_SOCK fornece uma camada de detecção de falhas sólida e por esta razão, tal técnica é utilizada em todas as configurações do JGroups inclusos no JBoss Application Server."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:598
@@ -1995,7 +1997,7 @@
"JOIN or LEAVE request arriving at the same time are bundled and handled "
"together at the same time, only sending out 1 new view / bundle. This is is "
"more efficient than handling each request separately."
-msgstr ""
+msgstr "<emphasis role=\"bold\">view_bundling</emphasis> especifica se as requisições do JOIN ou LEAVE múltiplo que chegam ao mesmo tempo, são agrupadas e manuseadas juntas, enviando somente uma nova visualização/conjunto. Isto é mais eficiente do que manusear cada requisição separadamente. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:720
@@ -2098,7 +2100,7 @@
"received after 5 seconds, then it sends an explicit credit request to the "
"receivers whose credits are currently below 0, until it receives credits "
"from all members whose credits are below 0."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_block_time</emphasis> especifica o tempo máximo (em ms) para bloqueio do remetente. Se um remetente estiver bloqueando, e nenhum credito for recebido após 5 segundos, ele envia uma requisição de crédito explícito para os destinatários, cujos créditos são abaixo de 0, até que ele receba créditos de todos os membros, cujos créditos forem abaixo de 0."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:755
@@ -2121,13 +2123,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 "Os aplicativos que usam chamadas do grupo síncrono RPC, não requerem o protocolo FC inicialmente em suas pilhas de protocolo de JGroup pois a comunicação síncrona, onde o segmento que faz a chamada bloqueia à espera de respostas de todos os membros do grupo, já diminue a velocidade da taxa de visão geral das chamadas. Embora o TCP forneça controle de fluxo por si mesmo, o FC ainda é requerido no TCP baseado em pilhas do JGroups, por causa da comunicação, onde nós inicialmente precisamos enviar mensagens de grupo na velocidade mais alta que o destinatário pode aguentar. O controle de fluxo do TCP leva em consideração somente as comunicações de nó individual e não tem noção de quem é o mais lento no grupo, razão pela qual o FC é requerido."
#. 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 que o FC é necessário acima do TCP? o TCP possui seu próprio controle de fluxo!"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:763
@@ -2143,7 +2145,7 @@
"group, it is possible that A, B and C receive the 100M, but D only received "
"1M messages. (BTW: this is also the reason why we need NAKACK, although TCP "
"does its own retransmission)."
-msgstr ""
+msgstr "A razão é a comunicação de grupo, onde nós incialmente precisamos enviar mensagens de grupo na velocidade mais alta o destinatário mais lento que puder aguentar. Vamos dizer que temos um cluster {A,B,C,D}. D é lento (talvez sobrecarregado), o restante é rápido. Quando o A envia uma mensagem de grupo, ele estabelece uma conesão TCP A-A (conceitualmente), A-B, A-C e A-D ( se ainda não existirem). Então, vamos dizer que o A envia 100 milhões de mensagens ao cluster. Como o controle de fluxo do TCP seaplica somente à A-B, A-C e A-D, mas não à A-{B,C,D}, onde {B,C,D} é o grupo, é possível que A, B e C recebam as 100 milhões de mensagens, mas D somente receberá 1 milhão de mensagens. (A propósito, esta também é a razão pela qual precisamos do NAKACK, embora o TCP faça suas próprias retransmissões)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:767
@@ -2156,7 +2158,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 "Agora o JGroup tem que bufferizar todas as mensagens em memórias para o caso de quando o remetente original S falhar e um nó pedir por uma retransmissão da mensagem do S. Como todos os membros bufferizam todas as mensagens que eles recebem, ele precisam limpar as mensagens estáveis (=mensagens vistas por todos) sempre que puderem. Isto é feito por um protocolo STABLE, que pode ser configurado para executar um protocolo de estabilidade baseado em tempo de retorno (ex.: a cada 50 seg.) ou baseado em tamanho (quando dados de 400K forem recebidos)."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:770
@@ -2168,7 +2170,7 @@
"protocol in TCP will cause writes to block if the window is full - we assume "
"in the above case that this is still much faster for A-B and A-C than for A-"
"D."
-msgstr ""
+msgstr "Nos casos acima, o nó lento D irá evitar que o grup limpe as mensagens acima de 1 milhão, para que todos os membros buferizem as 99 milhões de mensagens! Isto leva, na maioria dos casos, à exceções OOM. Observe que, embora um protocolo de janela suspensa no TCP faz com que as gravações bloqueiem se a janela estiver cheia, consideramos que no caso acima isto seja muito mais rápido para A-B e A-C do que para A-D."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:773
@@ -2176,7 +2178,7 @@
msgid ""
"So, in summary, we need to send messages at a rate the slowest receiver (D) "
"can handle."
-msgstr ""
+msgstr "Portanto, resumindo, precisamos enviar mensagens em uma classe que o destinatário mais lento (D) possa lidar."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:779
@@ -2192,7 +2194,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 "Isto depende de como o aplicativo usa o canal JGroups. Referindo-se ao exemplo acima, se existisse algo sobre o aplicativo que fizesse com que A diminuísse a velocidade da taxa de envio naturalmente, porque o D não conseguiu acompanhar, o FC não seria necessário. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:783
@@ -2204,7 +2206,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 "Um bom exemplo de uma aplicativo como este é um que faz as chamadas de RPC de grupo síncrono (geralmente usando um JGroup RpcDispatcher). Por sincronia, queremos dizer que o segmento que faz as chamadas bloquearem à espera por respostas de todos os membros do grupo. Neste tipo de aplicativo, os segmentos em A que estiverem fazendo as chamadas bloqueariam ao esperar por respostas por D, diminuindo assim a velocidade da taxa de chamadas gerais naturalmente. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:786
@@ -2214,7 +2216,7 @@
"application that makes synchronous group RPC calls. If a channel is only "
"used for a cache configured for REPL_SYNC, we recommend you remove FC from "
"its protocol stack."
-msgstr ""
+msgstr "Um cluster do JBoss Cache configurado por REPL_SYNC é um bom exemplo de um aplicativo que faz chamadas de RPC de grupos síncronos. Se um canal é usado somente para um cache configurado para REPL_SYNC, recomendamos que você remova o FC da pilha de protocolo. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:789
@@ -2224,7 +2226,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 "E claro, se seu cluster consistir de somente dois nós, é desnecessário incluir o FC em uma pilha de protocolos baseada em TCP, "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:792
@@ -2237,7 +2239,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 "Outro caso onde o FC pode não ser necessário é para um canal usado por um JBoss Cache configurado por uma replicação de buddy e um buddy único. Tal canal irá, em muitos aspectos, agir como um cluster de dois nós, onde mensagens são trocadas somente com um outro nó, o buddy. (Pode haver outras mensagens relacionadas à gravitação de dados que são enviadas para todos os membros, mas em caso de uso de uma replicação de buddy manuseada adequadamente, isto deve ser raro. Mas se você remover o FC, tenha a certeza de testar a carga de seu aplicativo)."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:802
@@ -2253,7 +2255,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 fragementa mensagens em um tamanho maior do que outros. Desfragmenta no lado do destinatário. Ele funciona para ambas mensagens unicast ou multicast. Ele é configurado no subelemento FRAG2 sob o elemento Config JGroup. Segue aqui uma configuração de amostra."
#. Tag: programlisting
#: Clustering_Guide_JBoss_Cache_JGroups.xml:806
@@ -2289,7 +2291,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 "O protocolo TCP já fornece a fragmentação mas o protocolo da fragmentação do JGroups ainda é necessário se o FC for usado. A razão para tal é que se você enviar uma mensagem maior do que FC.max_bytes, o protocolo do FC bloqueará. Portanto o frag_size dentro do FRAG2 precisa ser estabelecido para quase sempre menos do que o FC.max_bytes."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:826
@@ -2402,7 +2404,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 atrasos antes de enviarmos mensagens de STABILITY (dá chance à outros de enviar primeiro). Se usados juntos com o max_bytes, este atributo deve ser estabelecido em um número baixo."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:859
@@ -2492,13 +2494,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 "Os estados de cluster não são mesclados em um merger. Isto deve ser feito por um aplicativo. Se o <literal>MERGE2</literal> é usado em conjunto com o TCPPING, a função <literal>initial_hosts</literal> deve conter todos os nós que possam ser mesclado de volta, para que o processo de mesclagem funcione adequadamente. Caso contrário, o processo de mesclagem iria mesclar todos os nós, mesmo com a derivação desativada. Como forma alternativa, use o MPING, o qual é geralmente usado com o TCP para fornecer capacidades de descoberta de membros multicast, ao invés do TCPPING para evitar que precise especificar todos os nós."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:892
#, no-c-format
msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
+msgstr "Canais Binding JGroups para uma interface específica"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:893
@@ -2507,7 +2509,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 "Na seção dos Protocolos de Transporte acima, descrevemos resumidamente como a interface, para a qual o JGroup fará o 'bind' dos sockets, é configurada. Vamos tratar deste tópico com mais detalhes:"
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:896
@@ -2520,7 +2522,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 "Primeiro é importante entender que o conjunto de valores em qualquer elemento bind_addr em um arquivo de configuração XML será ignorado pelo JGroups se ele acreditar que a propriedade de sistema jgroups.bind_addr ( ou um nome mais recente obsoleto para a mesma coisa, <literal>bind.address</literal>) foi estabelecido. A propriedade de sistemas ultrapassa o XML. Se o JBoss AS é iniciado com a opção -b (ou --host), o AS irá ajsutar o <literal>jgroups.bind_addr</literal> para o valor especificado."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:899
@@ -2530,7 +2532,7 @@
"to localhost if -b is not set. The effect of this is that in most cases "
"users are going to be setting -b and thus jgroups.bind_addr is going to be "
"set and any XML setting will be ignored."
-msgstr ""
+msgstr "Iniciando com o AS 4.2.0, por razões de segurança o AS irá fazer o 'bind' da maioria dos serviços ao localhost se o -b não for configurado. O efeito disto é que, na maioria dos casos, os usuários irão configurar o -b e assim jgroups.bind_addr será configurado e qualquer configuração do XML será ignorado."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:902
@@ -2538,13 +2540,13 @@
msgid ""
"So, what are <emphasis>best practices</emphasis> for managing how JGroups "
"binds to interfaces?"
-msgstr ""
+msgstr "Portanto, quais são as <emphasis>melhores formas</emphasis> de gerenciar como o JGroups faz o 'bind' nas 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 "Vinculando (bind) JGroups à mesma interface que outros serviços. Simplesmente use o -b:"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:909
@@ -2562,6 +2564,8 @@
"property overrides the -b value. This is a common usage pattern; put client "
"traffic on one network, with intra-cluster traffic on another."
msgstr ""
+"Vinculando serviços (ex.: JBoss Web) à uma interface, mas use um diferente para o JGroups: <screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>. Configurar especialmente a propriedade de sistemas, sobrescreve o valor -b. Isto é um modelo de uso comum, colocao tráfego do cliente em uma rede, com o tráfego intra-cluster em outro."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:921
@@ -2573,7 +2577,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 "Vinculando serviços (ex.: JBoss Web) à todas as interfaces. Isto pode ser feito assim: <screen>./run.sh -b 0.0.0.0 -c all</screen>. No entanto, isto fazer com que o JGroups vincule-se à todas as interfaces! Ao invés disso, o JGroups irá vincular-se à interface padrão da máquina. Veja a seção dos Protocolos de Transporte para saber como informar JGroups a receber ou enviar em todas as interfaces, se você realmente quiser isto."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:929
@@ -2584,12 +2588,14 @@
"bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
"system property overrides the -b value."
msgstr ""
+"Vinculando serviços (ex.: JBoss Web) à todas as interfaces, mas especifique a interface do JGroups: <screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen> Novamente, ao configurar a propriedade do sistema especificamente, o valor -b será sobrescrito."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:937
#, no-c-format
msgid "Using different interfaces for different channels:"
-msgstr ""
+msgstr "Usando interfaces diferentes para canais diferentes:"
#. Tag: screen
#: Clustering_Guide_JBoss_Cache_JGroups.xml:939
@@ -2606,6 +2612,8 @@
"would need to edit the various XML configuration files to set the "
"<literal>bind_addr</literal> to the desired interfaces."
msgstr ""
+"Esta configuração diz informa ao JGroups para ignorar a propriedade de sistemas <literal>jgroups.bind_addr</"
+"literal>, e ao invés disso usar o que for especificado no XML. Você irá precisar editar diversos arquivos de configuração do XML para estabelecer o <literal>bind_addr</literal> para interfaces desejadas. "
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:949
@@ -2622,7 +2630,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 do JBoss AS, existe um número de serviços que cria canais do JGroups independentemente. -3 serviços do JBoss Cache diferentes (usados para replicação da HttpSession, replicação do EJB3 SFSB e replicação de entidade EJB3) junto com serviços de clustering de propósito geral chamado de HAPartition que é subjacente à maioria dos serviços JBossHA."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:953
@@ -2633,7 +2641,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 "É importante que estes canais se comuniquem somente com seus parceiros pretendidos, e não com canais usados por outros serviços e não com canais para o mesmo serviço aberto em máquinas que não sejam parte do grupo. A comunicação imprópria entre os nós é um dos problemas mais comuns que usuários encontram com o JBoss AS clustering."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:956
@@ -2643,7 +2651,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 "Com quem um canal do JGroups irá se comunicar, é definido por seu nome de grupo, endereço de multicast, e porta de multicast, para que os canais de JGroups isolados venham a assegurar que canais diferentes usam valores diferentes para o nome de grupo, endereço de multicast e porta de multicast. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:959
@@ -2652,7 +2660,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 canais de JGroups isolado para serviços diferentes no mesmo conjunto de instâncias de AS, você deve mudar o nome do grupo e a porta do multicast. Em outras palavras, cada canal deve ter seu próprio conjunto de valores."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:962
@@ -2663,7 +2671,7 @@
"clustering. The HAPartition channels should not communicate with the JBoss "
"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 ""
+msgstr "Por exemplo, digamos que temos um cluster de produção de 3 máquinas, cada uma com um HAPartition implementada com um JBoss Cache usado para o clustering da sessão da Web. Os canais do HAPartition não devem se comunicar com os canais do JBoss Cache. Eles devem usar um nome de grupo diferente e uma porta de multicast diferente. Eles podem usar o mesmo endereço de multicast, embora não seja necessário."
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:965
@@ -2672,7 +2680,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 isolar canais de JGroups para o mesmo serviço de outras instâncias do serviço na rede, você DEVE mudar TODOS os três valores. Cada canal deve possuir seu próprio nome de grupo, endereço de multicast, e porta de multicast. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:968
@@ -2683,7 +2691,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 exemplo, digamos que temos um cluster de produção de 3 máquinas, cada a qual com um HAPartition implementado. Na mesma rede, há também um cluster QA de 3 máquinas, cada o qual com um HAPartition implementado. O nome de grupo de HAPartition, endereço de multicast, e porta de multicast para as máquinas de produção devem ser diferentes daquelas usadas nas máquinas de QA."
#. Tag: title
#: Clustering_Guide_JBoss_Cache_JGroups.xml:974
@@ -2701,7 +2709,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 "O nome do grupo para um canal JGroup é configurado através do serviço que inicia o canal. Infelizmente, os serviços diferentes usam nomes de funções diferentes para configurar isto. Para o HAPartition e serviços relacionados configurados no arquivo deploy/cluster-service.xml, isto é configurado através da função PartitionName. Para os serviços do JBoss Cache, o nome da função é ClusterName. "
#. Tag: para
#: Clustering_Guide_JBoss_Cache_JGroups.xml:978
More information about the jboss-cvs-commits
mailing list