[jboss-cvs] JBossAS SVN: r84425 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Thu Feb 19 01:13:50 EST 2009


Author: croe at redhat.com
Date: 2009-02-19 01:13:49 -0500 (Thu, 19 Feb 2009)
New Revision: 84425

Modified:
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_JBoss_Cache_JGroups.po
Log:
Translation in progress

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po	2009-02-19 05:53:23 UTC (rev 84424)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po	2009-02-19 06:13:49 UTC (rev 84425)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Clustering_Guide_Introduction\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-15 03:45+0000\n"
-"PO-Revision-Date: 2009-02-18 16:07+1000\n"
+"PO-Revision-Date: 2009-02-19 15:03+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -1277,7 +1277,7 @@
 "get a valid HA-JNDI server node without any configuration. Of course, for "
 "auto-discovery to work, the network segment(s) between the client and the "
 "server cluster must be configured to propagate such multicast datagrams."
-msgstr "Si la chaîne de propriété java.naming.provider.url est vide ou si tous les serveurs qu'il mentionne ne sont pas joignables, le client JNP va essayer de découvrir le serveur HA-JNDI par l'intermédiaire d'un appel multicast sur le réseau (auto-discorvery). Voir la section qui s'intitule \"JBoss configuration\" sur la façon de configurer auto-discovery sur les noeuds de serveur JNDI. Avec auto-discovery, le client peut être en mesure d'obtenir un noeud de serveur HA-JNDI en cours de validité, sans aucune configuration. Biensûr, pour qu'auto-discovery fonctionne, le(s) segment(s) de réseau entre le client et le cluster du serveur, doit(doivent) être configuré(s) pour propager de tels datagrammes multi-diffusion."
+msgstr "Si la chaîne de propriété java.naming.provider.url est vide ou si tous les serveurs qu'il mentionne ne sont pas joignables, le client JNP va essayer de découvrir le serveur HA-JNDI par l'intermédiaire d'un appel multicast sur le réseau (auto-discorvery). Voir la section qui s'intitule \"JBoss configuration\" sur la façon de configurer auto-discovery sur les noeuds de serveur JNDI. Avec auto-discovery, le client peut être en mesure d'obtenir un noeud de serveur HA-JNDI en cours de validité, sans aucune configuration. Biensûr, pour qu'auto-discovery fonctionne, le(s) segment(s) de réseau entre le client et le cluster du serveur, doit(doivent) être configuré(s) pour propager de tels datagrammes multicast."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:484
@@ -1478,7 +1478,7 @@
 msgid ""
 "<literal>DiscoveryDisabled</literal> is a boolean flag that disables "
 "configuration of the auto discovery multicast listener."
-msgstr "<literal>DiscoveryDisabled</literal> est une balise booléenne qui désactive la configuration du listener multi-diffusion d'auto-discovery."
+msgstr "<literal>DiscoveryDisabled</literal> est une balise booléenne qui désactive la configuration du listener multicast d'auto-discovery."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:558
@@ -1490,7 +1490,7 @@
 "system property, or 230.0.0.4 if that is not set. The jboss.partition."
 "udpGroup system property is set if the -u command line switch is used when "
 "JBoss is started."
-msgstr "<emphasis role=\"bold\">AutoDiscoveryAddress</emphasis> est un attribut optionnel qui spécifie l'adresse multi-diffusion pour écouter pour automatic-discovery JNDI. La valeur par défaut est la valeur de la propriété de système jboss.partition.udpGroup,  ou 230.0.0.4 si elle n'est pas configurée. La propriété de système udpGroup est fixée si le commutateur de ligne de commande -u est utilisé quand JBoss démarre."
+msgstr "<emphasis role=\"bold\">AutoDiscoveryAddress</emphasis> est un attribut optionnel qui spécifie l'adresse multicast pour écouter pour automatic-discovery JNDI. La valeur par défaut est la valeur de la propriété de système jboss.partition.udpGroup,  ou 230.0.0.4 si elle n'est pas configurée. La propriété de système udpGroup est fixée si le commutateur de ligne de commande -u est utilisé quand JBoss démarre."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:561
@@ -1499,7 +1499,7 @@
 "<emphasis role=\"bold\">AutoDiscoveryGroup</emphasis> is an optional "
 "attribute to specify the multicast group to listen to for JNDI automatic "
 "discovery.. The default value is <literal>1102</literal>."
-msgstr "<emphasis role=\"bold\">AutoDiscoveryGroup</emphasis> est un attribut optionnel qui spécifie le groupe multi-diffusion qu'il faut écouter pour automatic-discovery JNDI. La valeur par défaut est <literal>1102</literal>."
+msgstr "<emphasis role=\"bold\">AutoDiscoveryGroup</emphasis> est un attribut optionnel qui spécifie le groupe multicast qu'il faut écouter pour automatic-discovery JNDI. La valeur par défaut est <literal>1102</literal>."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:567
@@ -1520,7 +1520,7 @@
 "number of network hops a multicast packet can be allowed to propagate before "
 "networking equipment should drop the packet. Despite its name, it does not "
 "represent a unit of time."
-msgstr "<emphasis role=\"bold\">AutoDiscoveryTTL</emphasis> spécifie le TTL (time-to-live / durée de vie) pour les paquets multi-diffusion IP autodiscovey. Cette valeur représente le nombre de sauts de réseau (network hop) qu'un paquet multi-diffusion est autorisé à propager avant que l'équipement de réseautage puisse abandonner le paquet. Malgré son nom, il ne représente pas une unité temporelle."
+msgstr "<emphasis role=\"bold\">AutoDiscoveryTTL</emphasis> spécifie le TTL (time-to-live / durée de vie) pour les paquets multicast IP autodiscovey. Cette valeur représente le nombre de sauts de réseau (network hop) qu'un paquet multicast est autorisé à propager avant que l'équipement de réseautage puisse abandonner le paquet. Malgré son nom, il ne représente pas une unité temporelle."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:573
@@ -6948,7 +6948,7 @@
 "addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</"
 "literal>\"."
 msgstr ""
-"<emphasis role=\"bold\">receive_interfaces</emphasis> précise une liste d'interfaces qui accueillent des multi-diffusions. La connexion de réception de multi-diffusion écoutera toutes ces interfaces. C'est une liste séparée-par-virgule d'adresses IP ou de noms d'interfaces. Par exemple  \"<literal>192.168.5.1,eth1,127.0.0.1</"
+"<emphasis role=\"bold\">receive_interfaces</emphasis> précise une liste d'interfaces qui accueillent des multicasts. La connexion de réception de multicast écoutera toutes ces interfaces. C'est une liste séparée-par-virgule d'adresses IP ou de noms d'interfaces. Par exemple  \"<literal>192.168.5.1,eth1,127.0.0.1</"
 "literal>\"."
 
 #. Tag: para
@@ -7331,13 +7331,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 "PNG est un protocole discovery qui fonctionne soit en diffusant multiple requêtes PING vers une adresse IP multi-diffusion, ou bien en se connectant à un router gossip. Ainsi, PING est normalement situé au dessus des protocoles de transport TUNNEL ou UDP. Chaque noeud répond avec un paquet {C, A}, pour lequel C= l'adresse du coordinateur et A= sa propre adresse. Après avoir obtenu une réponse de timeout milleseconds ou de num_initial_members, le nouveau venu détermine le coordinateur à partir des réponses, et envoie lui une requête JOINTE. Si personne ne répond, on assume que nous sommes les premiers membres d'un groupe."
+msgstr "PNG est un protocole discovery qui fonctionne soit en diffusant multiple requêtes PING vers une adresse IP multicast, ou bien en se connectant à un router gossip. Ainsi, PING est normalement situé au dessus des protocoles de transport TUNNEL ou UDP. Chaque noeud répond avec un paquet {C, A}, pour lequel C= l'adresse du coordinateur et A= sa propre adresse. Après avoir obtenu une réponse de timeout milleseconds ou de num_initial_members, le nouveau venu détermine le coordinateur à partir des réponses, et envoie lui une requête JOINTE. Si personne ne répond, on assume que nous sommes les premiers membres d'un groupe."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1969
 #, no-c-format
 msgid "Here is an example PING configuration for IP multicast."
-msgstr "Voici un exemple de configuration PING pour IP multi-diffusion."
+msgstr "Voici un exemple de configuration PING pour IP multicast."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1973
@@ -7592,7 +7592,7 @@
 "when we want TCP as transport, but multicasting for discovery so we don't "
 "have to define a static list of initial hosts in TCPPING or require external "
 "Gossip Router."
-msgstr "MPING utilise IP multi-diffusion pour découvrir l'affiliation initiale. Cela peut être utilisé avec tous les transports, mais c'est normalement utilisé en combinaison avec TCP. TCP a normalement besoin de TCPPING, qui doit lister tous les membres du groupe explicitement, mais MPING n'est pas lié à cette exigence. Le cas d'utilisation typique, c'est quand on souhaite avoir TCP comme transport, mais multi-diffusion pour discovery, de façon à ce qu'on n'ait pas à définir la liste statique d'hôtes initiaux dans TCPPING, ni besoin de Router Gossip externe."
+msgstr "MPING utilise IP multicast pour découvrir l'affiliation initiale. Cela peut être utilisé avec tous les transports, mais c'est normalement utilisé en combinaison avec TCP. TCP a normalement besoin de TCPPING, qui doit lister tous les membres du groupe explicitement, mais MPING n'est pas lié à cette exigence. Le cas d'utilisation typique, c'est quand on souhaite avoir TCP comme transport, mais multicast pour discovery, de façon à ce qu'on n'ait pas à définir la liste statique d'hôtes initiaux dans TCPPING, ni besoin de Router Gossip externe."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2089
@@ -7637,7 +7637,7 @@
 msgid ""
 "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on "
 "which to send and receive multicast packets."
-msgstr "<emphasis role=\"bold\">bind_addr</emphasis> détermine l'interface sur laquelle envoyer et recevoir les paquets multi-diffusion."
+msgstr "<emphasis role=\"bold\">bind_addr</emphasis> détermine l'interface sur laquelle envoyer et recevoir les paquets multicast."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2107
@@ -8083,7 +8083,7 @@
 "retransmit the missing message. The NAKACK protocol is configured as the "
 "<literal>pbcast.NAKACK</literal> sub-element under the JGroups "
 "<literal>Config</literal> element. Here is an example configuration."
-msgstr "Le protocole NAKAK est utilisé pour les messages multi-diffusion. Il utilise NAK. Sous ce protocole, chaque message est balisé par un numéro de séquence. Le récepteur garde la trace des nombres de séquences et délivre les messages dans l'ordre. Quand on détecte un manquement dans les numéros de séquence, le récepteur demande à l'émetteur de retransmettre le message manquant. Le protocole NAKACK est configuré comme un sous-élément de <literal>pbcast.NAKACK</literal> sous l'élément de JGroups <literal>Config</literal> element. Voici un exemple de configuration."
+msgstr "Le protocole NAKAK est utilisé pour les messages multicast. Il utilise NAK. Sous ce protocole, chaque message est balisé par un numéro de séquence. Le récepteur garde la trace des nombres de séquences et délivre les messages dans l'ordre. Quand on détecte un manquement dans les numéros de séquence, le récepteur demande à l'émetteur de retransmettre le message manquant. Le protocole NAKACK est configuré comme un sous-élément de <literal>pbcast.NAKACK</literal> sous l'élément de JGroups <literal>Config</literal> element. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2336
@@ -8292,7 +8292,7 @@
 "control service is configured in the <literal>FC</literal> sub-element under "
 "the JGroups <literal>Config</literal> element. Here is an example "
 "configuration."
-msgstr ""
+msgstr "Le service de contrôle des flux essaie d'adapter le taux d'émission des données et des données collectées entre les noeuds. Si un noeud d'émission est trop rapide, il risque de submerger le noeud récepteur et résulter en paquets largués ayant besoin d'être retransmis. Dans JGroups, le contrôle de flux est implémenté par un système basé-crédit. Les noeuds récepteurs et émetteurs ont le même nombre de crédits (octets) pour commencer. L'émetteur soustrait ses crédits par le nombre d'octets présents dans le message qu'il reçoit. Quand le nombre de crédits diminue au delà d'un certain seuil, le récepteur renvoie quelques crédits à l'émetteur. Si les crédits de l'émetteur sont totalement utilisés, l'émetteur est bloqué jusqu'à ce qu'il reçoive des crédits de la part de l'émetteur. Le service de contrôle de flux est configuré dans le sous-élément <literal>FC</literal> sous l'élément <literal>Config</literal>. Voici un exemple de!
  configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2435
@@ -8323,7 +8323,7 @@
 msgid ""
 "<emphasis role=\"bold\">max_credits</emphasis> specifies the maximum number "
 "of credits (in bytes). This value should be smaller than the JVM heap size."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_credits</emphasis> précise le nombre maximum de crédits (en octets). Cette valeur devrait être inférieure à la taille du tas JVM."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2445
@@ -8331,7 +8331,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_credits</emphasis> specifies the threshold "
 "credit on the sender, below which the receiver should send in more credits."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_credits</emphasis> détermine de seuil de crédit de l'émetteur, en dessous duquel le récepteur devrait envoyer plus de crédits."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2449
@@ -8339,7 +8339,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_threshold</emphasis> specifies percentage value "
 "of the threshold. It overrides the <literal>min_credits</literal> attribute."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_threshold</emphasis> détermine la valeur du pourcentage du seuil de tolérance. Il prend précédent sur l'attribut <literal>min_credits</literal>."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2455
@@ -8355,7 +8355,7 @@
 "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 "Les applications qui utilisent les appels RPC de groupe synchronisés, n'ont pas foncièrement besoin du protocole FC dans leur pile de protocole JGroups car la communication synchrône, où le thread qui fait l'appel bloque en attendant des réponses de la part de tous les membres du groupe, ralentit déjà le taux moyen des appels. Même si TCP fournit un contrôle de flux en soi, on a toujours besoins de FC pour les piles JGroups basées TCP en raison de la communication de groupe, pour laquelle on doit essentiellement envoyer des messages de groupe à la vitesse la plus élevée tolérable par le récepteur le plus lent. Le contrôle de flux TCP ne prend en considération que les communications des noeuds individuels et n'a aucune notion de qui est le plus lent dans le groupe, et c'est la raison pour laquelle on a besoin de FC."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2464
@@ -8371,7 +8371,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 "Ce protocole fragmente des messages supérieurs à une certaine taille. Défragmente du côté du récepteur. Cela fonctionne à la fois pour les messages unicast et les messages multicast. Il est configuré dans le sous-élément FRAG2 sous l'élément JGroups Config. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2468
@@ -8389,7 +8389,7 @@
 #: Clustering_Guide_Introduction.xml:2470
 #, no-c-format
 msgid "The configurable attributes in the FRAG2 element are as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément FRAG2 sont les suivants."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2475
@@ -8397,7 +8397,7 @@
 msgid ""
 "<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in "
 "bytes. Messages larger than that are fragmented."
-msgstr ""
+msgstr "<emphasis role=\"bold\">frag_size</emphasis> détermine la taille maximum de fragmentation en octets. Les plus grands messages seront fragmentés."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2479
@@ -8407,7 +8407,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 "Le protocole TCP procure déjà une fragmentation, mais un protocole JGroups de fragmentation est toujours requis si FC est utilisé. La raison pour cela, c'est que si vous envoyez un message plus grand que FC.max_bytes, le protocole FC bloquerait. Donc, dans FRAG2, frag_size aura besoin d'être toujours inférieur à FC.max_bytes."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2490
@@ -8424,7 +8424,7 @@
 "<literal>pbcast.STATE_TRANSFER</literal> sub-element under the JGroups "
 "<literal>Config</literal> element. It does not have any configurable "
 "attribute. Here is an example configuration."
-msgstr ""
+msgstr "Le service de transfert d'états transfère l'état à partir d'un noeud existant (c'est à dire, le coordinateur du cluster) sur un noeud nouvellement rejoint. Il est configuré dans le sous-élément <literal>pbcast.STATE_TRANSFER</literal> sous l'élément <literal>Config</literal>. Il n'a pas d'attribut configurable. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2495
@@ -8436,7 +8436,7 @@
 #: Clustering_Guide_Introduction.xml:2502
 #, no-c-format
 msgid "Distributed Garbage Collection"
-msgstr ""
+msgstr "Service de nettoyage de la mémoire distribué"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2503
@@ -8450,7 +8450,7 @@
 "service is configured in the <literal>pbcast.STABLE</literal> sub-element "
 "under the JGroups <literal>Config</literal> element. Here is an example "
 "configuration."
-msgstr ""
+msgstr "Dans un cluster JGroups, tous les noeuds doivent stocker tous les messages reçus en vue de retransmission potentielle, en cas de défaillance. Cependant, si on stocke tous les messages indéfiniement, nous allons manquer d'espace mémoire. Donc, le service de nettoyage distribué de JGroups purge périodiquement les messages identifiés par les noeuds de la mémoire, pour chaque noeud. Le service de nettoyage distribué est configuré dans le sous-élément <literal>pbcast.STABLE</literal> sous l'élément JGroups <literal>Config</literal>. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2507
@@ -8472,7 +8472,7 @@
 msgid ""
 "The configurable attributes in the <literal>pbcast.STABLE</literal> element "
 "are as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément <literal>pbcast.STABLE</literal> sont les suivants :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2512
@@ -8482,6 +8482,9 @@
 "(in milliseconds) of garbage collection runs. Value <literal>0</literal> "
 "disables this service."
 msgstr ""
+"<emphasis role=\"bold\">desired_avg_gossip</emphasis> détermine les intervalles"
+"(en millesecondes) entre les sessions de nettoyage. La valeur <literal>0</literal> "
+"désactive ce service."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2517
@@ -8490,7 +8493,7 @@
 "<emphasis role=\"bold\">max_bytes</emphasis> specifies the maximum number of "
 "bytes received before the cluster triggers a garbage collection run. Value "
 "<literal>0</literal> disables this service."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_bytes</emphasis> détermine le nombre maximum d'octets reçus avant qu'un cluster ne déclenche un nettoyage. La valeur <literal>0</literal> désactive ce service."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2522
@@ -8499,7 +8502,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> détermine le délai précédant l'envoi d'un msg STABILITY (ce qui donne une chance aux autres d'envoyer avant). Si c'est utilisé en conjonction avec max_bytes, cet attribut devrait être paramétré avec un nombre inférieur."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2526
@@ -8507,7 +8510,7 @@
 msgid ""
 "Set the <literal>max_bytes</literal> attribute when you have a high traffic "
 "cluster."
-msgstr ""
+msgstr "Paramétrez l'attribut <literal>max_bytes</literal> quand vous avez un haut volume de trafic dans le cluster."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2531
@@ -8525,7 +8528,7 @@
 "cluster back again. The flow control service is configured in the "
 "<literal>MERGE2</literal> sub-element under the JGroups <literal>Config</"
 "literal> element. Here is an example configuration."
-msgstr ""
+msgstr "Quand on a une erreur de réseau, le cluster peut être partitionné en plusieurs partitions séparées. JGroups possède une service MERGE (FUSION) qui permet aux coordinateurs des partitions de communiquer les uns avec les autres pour finalement reformer un cluster unique. Le service de contrôle de flux est configuré dans le sous-élément <literal>MERGE2</literal> sous l'élément JGroups <literal>Config</literal>. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2536
@@ -8545,7 +8548,7 @@
 msgid ""
 "<emphasis role=\"bold\">max_interval</emphasis> specifies the maximum number "
 "of milliseconds to send out a MERGE message."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_interval</emphasis> détermine le nombre maximum de millesecondes avant d'envoyer un message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2546
@@ -8553,7 +8556,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_interval</emphasis> specifies the minimum number "
 "of milliseconds to send out a MERGE message."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_interval</emphasis> détermine le nombre minimum de millesecondes pour envoyer un message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2550
@@ -8562,11 +8565,12 @@
 "JGroups chooses a random value between <literal>min_interval</literal> and "
 "<literal>max_interval</literal> to send out the MERGE message."
 msgstr ""
+"JGroups choisit une valeur au hasard entre <literal>min_interval</literal> et "
+"<literal>max_interval</literal> pour envoyer le message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2553
 #, no-c-format
-#, fuzzy
 msgid ""
 "The cluster states are not merged in a merger. This has to be done by the "
 "application. If <literal>MERGE2</literal> is used in conjunction with "
@@ -8576,13 +8580,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 "<literal></literal> TCPPING<literal></literal> MPING TCPPING."
+msgstr "Les états du cluster ne sont pas fusionnés dans un merger. Cela doit être fait par l'application. Si <literal>MERGE2</literal> est utilisé en conjonction avec TCPPING, l'attribut <literal>initial_hosts</literal> devra contenir tous les noeuds qui pourraient être potentiellement fusionnés à nouveau, pour que le processus de fusionnement fonctionne correctement. Sinon, le processus de fusionnement ne s'appliquerait pas tous les noeuds, même si shunning (exclusion) était désactivé. Sinon, utiliser MPING, qui est normalement utilisé avec TCP pour offrir des capacités discovery aux membre multicast, à la place de TCPPING pour éviter d'avoir à spécifier tous les noeuds."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2559
 #, no-c-format
 msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
+msgstr "Lier les canaux JGroups à une interface particulière"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2560
@@ -8591,7 +8595,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 "Dans la section Protocoles de Transport ci-dessus, nous abordons brièvement comment l'interface par laquelle JGroups va lier les sockets, est configurée. Penchons-nous davantage sur ce sujet :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2563
@@ -8604,7 +8608,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 "Tout d'abord, il est important de comprendre que la valeur déterminée dans n'importe quel élément bind_addr d'un fichier de configuration XML, sera ignoré par JGroups s'il établit que la propriété de système jgroups.bind_addr (ou un ancien nom s'appliquant à la même chose, <literal>bind.address</literal>) a été déterminée. La propriété de système éclipse XML. Si JBoss AS commence par le commutateur -b (ou bien --host), AS configurera <literal>jgroups.bind_addr</literal> avec une valeur spécifique."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2566
@@ -8614,7 +8618,7 @@
 "binds most services 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 "En commençant par AS 4.2.0, le serveur JBoss Application relie la plupart des services à l'hôte local si -b n'est pas déterminé. L'effet, c'est que, dans la plupart des cas, les utilisateurs vont configurer -b et donc jgroups.bind_addr sera configuré et toute configuration XML sera ignorée."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2569
@@ -8622,13 +8626,13 @@
 msgid ""
 "So, what are <emphasis>best practices</emphasis> for managing how JGroups "
 "binds to interfaces?"
-msgstr ""
+msgstr "Donc, quelles sont les <emphasis>meilleures pratiques</emphasis> pour gérer comment JGroups fait la liaison avec interfaces ?"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2574
 #, no-c-format
 msgid "Binding JGroups to the same interface as other services. Simple, just use -b:"
-msgstr ""
+msgstr "Pour relier JGroups à la même interface que les autres services, utilisez simplement -b :"
 
 #. Tag: screen
 #: Clustering_Guide_Introduction.xml:2576
@@ -8646,6 +8650,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 ""
+"Relier les services (par ex., JBoss Web) à une interface, mais utiliser une interface différente pour JGroups : <screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>. Paramétrer une propriété système prévaut sur la valeur -b. C'est un usage courant qui consiste à mettre le trafic client sur un réseau, et le trafic intra-cluster sur un autre."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2588
@@ -8657,7 +8663,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 "Relier les services (par ex. JBoss Web) à toutes les interfaces. Cela pourrait être fait de cette façon : <screen>./run.sh -b 0.0.0.0 -c all</screen>. Cependant, cela n'amènera pas JGroups à se relier à toutes les interfaces ! A la place, JGroups se reliera à l'interface par défaut de la machine. Voir la section Protocoles de Transport pour la façon d'indiquer à JGroups comment recevoir en émettre sur toutes les interfaces, si c'est vraiment ce que vous souhaitez."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2596
@@ -8668,12 +8674,14 @@
 "bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
 "system property overrides the -b value."
 msgstr ""
+"Relier les services (par ex. JBoss Web) à toutes les interfaces, mais préciser l'interface JGroups : <screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>. Ici aussi, configurer spécifiquement la propriété du système prévaut sur la valeur -b."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2604
 #, no-c-format
 msgid "Using different interfaces for different channels:"
-msgstr ""
+msgstr "Utiliser des interfaces différentes pour des canaux différents :"
 
 #. Tag: screen
 #: Clustering_Guide_Introduction.xml:2606
@@ -8689,7 +8697,7 @@
 "literal> system property, and instead use whatever is specfied in XML. You "
 "would need to edit the various XML configuration files to set the "
 "<literal>bind_addr</literal> to the desired interfaces."
-msgstr ""
+msgstr "Cette configuration indique à JGroups d'ignorer la propriété de système <literal>jgroups.bind_addr</, et utiliser à la place ce qui est spécifié dans XML. Vous devrez éditer les divers fichiers de configuration pour paramétrer <literal>bind_addr</literal> aux interfaces désirées."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2616
@@ -8700,14 +8708,13 @@
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2617
 #, no-c-format
-#, fuzzy
 msgid ""
 "Within JBoss AS, there are a number of services that independently create "
 "JGroups channels -- 3 different JBoss Cache services (used for HttpSession "
 "replication, EJB3 SFSB replication and EJB3 entity replication) along with "
 "the general purpose clustering service called HAPartition that underlies "
 "most other JBossHA services."
-msgstr "HAPartition."
+msgstr "Dans JBoss AS, il existe un certain nombre de services qui créent indépendemment des canaux JGroups -- 3 services JBoss Cache différents (utilisés pour la replication de session Http, la réplication EJB3 SFSB, et la réplication d'entité EJB3), accompagnés du service de clustering d'intérêt général, nommé HAPartition qui est à la base de la plupart des autres services JBossHA."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2620
@@ -8718,7 +8725,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 "Il est critique que ces canaux puissent uniquement communiquer avec leurs homologues spécifiques, et non pas à travers les canaux utilisés par d'autres services, ni avec des canaux du même service disponible à des machines qui ne devraient pas faire partie du groupe. Le fait que les noeuds puissent mal communiquer entre eux, est l'un des problèmes les plus courants auxquels les utilisateurs puissent rencontrer avec le clustering JBoss."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2623
@@ -8728,7 +8735,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 "Le nom de groupe, l'adresse multicast, et le port multicast définissent avec qui un canal JGroups pourra communiquer. Donc, pour isoler les canaux JGroups, il s'agit de veiller à ce que différents canaux utilisent des valeurs différentes pour le nom de groupe, l'adresse multicast et le port multicast."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2626
@@ -8737,19 +8744,18 @@
 "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 "Pour isoler les canaux JGroups sur différents services sur le même groupe d'instances AS, vous DEVEZ changer le nom du groupe et le port multicast. En d'autres mots, chaque canal doit posséder son propre ensemble de valeurs."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2629
 #, no-c-format
-#, fuzzy
 msgid ""
 "For example, say we have a production cluster of 3 machines, each of which "
 "has an HAPartition deployed along with a JBoss Cache used for web session "
 "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 "HAPartition HAPartition."
+msgstr "Ainsi, imaginons que nous ayons un cluster de production de 3 machines, possédant chacune une HAPartition déployée aux côté d'un JBoss Cache utilisé pour le clustering de sessions web. Les canaux HAPartition ne devraient pas communiquer avec les canaux JBoss Cache. Ils devraient utiliser un nom de groupe et un port multicast différents. Ils peuvent utiliser la même adresse multicast, mais ils ne sont pas obligés."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2632
@@ -8758,19 +8764,18 @@
 "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 "Pour isoler les canaux JGroups d'autre instances du service sur le réseau, pour un même service, vous DEVEZ changer TOUTES les trois valeurs. Chaque canal doit avoir son propre nom de groupe, son adresse multicast et son port multicast."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2635
 #, no-c-format
-#, fuzzy
 msgid ""
 "For example, say we have a production cluster of 3 machines, each of which "
 "has an HAPartition deployed. On the same network there is also a QA cluster "
 "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 "HAPartition HAPartition HAPartition."
+msgstr "Ainsi, imaginons que nous ayons un cluster de production de 3 machines, possédant chacune une HAPartition déployée. Sur ce même réseau, il y a aussi un cluster QA de 3 machines, avec HAPartition de déployé également. Le nom de groupe, l'adresse multicast, et le port multicast HAPartition des machines de production doivent être différents de ceux qui sont utilisés sur les machines QA."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2641
@@ -8781,7 +8786,6 @@
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2642
 #, no-c-format
-#, fuzzy
 msgid ""
 "The group name for a JGroups channel is configured via the service that "
 "starts the channel. Unfortunately, different services use different "
@@ -8789,12 +8793,11 @@
 "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 "HAPartition."
+msgstr "Le nom de groupe des canaux JGroups est configuré par le service qui démarre le canal. Malheureusement, des services différents utilisent des noms d'attribut différents pour le configurer. Pour la partition HAPartition et les services liés, configurés dans le fichier depoy/cluster-service.xml, c'est configuré par un attribut PartitionName. Pour les services Jboss Cache, le nom de l'attribut est ClusterName."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2645
 #, no-c-format
-#, fuzzy
 msgid ""
 "Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss "
 "Cache services, we make it easy for you to create unique groups names simply "
@@ -8803,7 +8806,9 @@
 "jboss.partition.name system property, which is used as a component in the "
 "configuration of the group name in all the standard clustering configuration "
 "files. For example,"
-msgstr "HAPartition<screen></screen>"
+msgstr ""
+"En commençant avec JBoss AS 4.0.4, pour HAPartition et pour tous les services standards JBoss Cache, nous facilitons la création des noms de groupes uniques, en utilisant simplement le commutateur -g (ou -partition) au moment du démarrage de JBoss :<screen>./"
+"run.sh -g QAPartition -b 192.168.1.100 -c all</screen>. Ce commutateur définit la propriété de système jboss.partition.name, qui est utilisée en tant que composant de la configuration du nom de groupe dans tous les fichiers de configuration de clustering standards. Ainsi,"
 
 #. Tag: screen
 #: Clustering_Guide_Introduction.xml:2649
@@ -8819,12 +8824,11 @@
 #: Clustering_Guide_Introduction.xml:2655
 #, no-c-format
 msgid "Changing the multicast address and port"
-msgstr "Changer l'adresse multi-diffusion et le port"
+msgstr "Changer l'adresse multicast et le port"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2656
 #, no-c-format
-#, fuzzy
 msgid ""
 "The -u (a.k.a. --udp) command line switch may be used to control the "
 "multicast address used by the JGroups channels opened by all standard AS "
@@ -8832,7 +8836,10 @@
 "192.168.1.100 -c all]]></screen> This switch sets the jboss.partition."
 "udpGroup system property, which you can see referenced in all of the "
 "standard protocol stack configs in JBoss AS:"
-msgstr "commande<screen></screen>:"
+msgstr ""
+"La ligne de commande -u (a.k.a. --udp) peut être utilisée pour contrôler l'adresse multicast utilisée par les canaux JGroups qui sont ouverts par tous les services AS standard. <screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b "
+"192.168.1.100 -c all]]></screen> Ce commutateur détermine la propriété de système jboss.partition."
+"udpGroup, que vous pouvez voir référencée dans toutes les configurations de piles de protocoles standards dans JBoss AS."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2662
@@ -8849,7 +8856,6 @@
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2663
 #, no-c-format
-#, fuzzy
 msgid ""
 "Unfortunately, setting the multicast ports is not so simple. As described "
 "above, by default there are four separate JGroups channels in the standard "
@@ -8857,7 +8863,7 @@
 "are no command line switches to set these, but the standard configuration "
 "files do use system properties to set them. So, they can be configured from "
 "the command line by using -D. For example,"
-msgstr "commande commande"
+msgstr "Malheureusement, configurer les ports multicast n'est pas une tâche simple. Comme nous l'avons décrit plus haut, il existe par défaut quatre canaux JGroups séparés dans la configuraiton JBoss AS all, et chaque canal devrait être associé à un port unique. Il n'y a pas de commutateurs de lignes de commande pour les installer, mais les fichiers de configuration standard utilisent des propriétés de système pour les configurer. Ainsi, ils peuvent être configurés à partir de la ligne de commande en utilisant -D. Par exemple,"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:2666
@@ -8887,13 +8893,13 @@
 "port, the lower level JGroups protocols in each channel will see, process "
 "and eventually discard messages intended for the other group. This will at a "
 "minimum hurt performance and can lead to anomalous behavior."
-msgstr ""
+msgstr "Si des canaux associés à des noms de groupe différents partagent le mêm port et la même adresse multicast, les protocoles JGroups de bas niveau, pour chaque canal, trouvera, traitera et finalement se débarrassera de messages destinés à l'autre groupe. Cela aura pour conséquence de diminuer la performance, au minimum, voire entraîner dun comportement anormal."
 
 #. Tag: emphasis
 #: Clustering_Guide_Introduction.xml:2673
 #, no-c-format
 msgid "Why do I need to change the multicast port if I change the address?"
-msgstr "Pourquoi devrais-je changer le port multi-diffusion si je change l'adresse ?"
+msgstr "Pourquoi devrais-je changer le port multicast si je change l'adresse ?"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2674
@@ -8904,7 +8910,7 @@
 "multicast port are delivered to all listeners on that port, regardless of "
 "the multicast address they are listening on. So the recommendation is to "
 "change both the address and the port."
-msgstr ""
+msgstr "Changer l'adresse uniquement devrait suffire, mais il existe un problème sur plusieurs systèmes d'exploitation, quand des paquets adressés à un port particulier multicast, sont livrés à tous les listeners de ce port, quelque soit l'adresse multicast sur laquelle ils sont branchés. Donc, la recommandation est de changer à la fois l'adresse et le port."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2680
@@ -8927,6 +8933,9 @@
 "McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> "
 "directory and start McastReceiverTest, for example:"
 msgstr ""
+"Veillez à ce que votre machine soit configurée correctement pour IP multicast. Il existe 2 programmes test qui peuvent être utilisés pour le détecter :  McastReceiverTest et "
+"McastSenderTest. Aller dans le répertoire<literal>$JBOSS_HOME/server/all/lib</literal> "
+"et démarrez McastReceiverTest, par exemple :"
 
 #. Tag: screen
 #: Clustering_Guide_Introduction.xml:2685
@@ -8962,12 +8971,11 @@
 "<literal>-bind_addr 192.168.0.2</literal>, where 192.168.0.2 is the IP "
 "address of the NIC to which you want to bind. Use this parameter in both the "
 "sender and the receiver."
-msgstr ""
+msgstr "Si vous souhaitez vous relier à une carte d'interface de réseau (NIC) précise, utilisez <literal>-bind_addr 192.168.0.2</literal>, où 192.168.0.2 est l'adresse IP du NIC auquel vous souhaitez vous relier. Utiliser ce paramètre à la fois pour l'émetteur et le récepteur."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2696
 #, no-c-format
-#, fuzzy
 msgid ""
 "You should be able to type in the <literal>McastSenderTest</literal> window "
 "and see the output in the <literal>McastReceiverTest</literal> window. If "
@@ -8978,7 +8986,7 @@
 "Once you know multicast is working properly on each machine in your cluster, "
 "you can repeat the above test to test the network, putting the sender on one "
 "machine and the receiver on another."
-msgstr "<literal></literal> sortie<literal></literal>."
+msgstr "Vous devriez pouvoir saisir des informations dans la fenêtre <literal>McastSenderTest</literal> et observer la sortie dans la fenêtre <literal>McastReceiverTest</literal>. Sinon, essayez d'utiliser -ttl 32 pour l'émetteur. Si cela échoue également, consultez l'administrateur de systèmes pour vous aider à installer IP multicast correctement, et demandez à l'administrateur de veiller à ce que multicast fonctionne sur l'interface que vous avez choisie, ou bien, si les machines ont des interfaces multiples, exigez de connaître l'interface qui convient. Une fois que multicast fonctionne correctement sur chaque machine du cluster, vous pourrez répéter le test ci-dessus pour tester le réseau, en mettant l'émetteur sur une machine et le récepteur sur une autre."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:2708
@@ -8994,7 +9002,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 "Parfois, un membre est rendu suspect par FD car un ACK heartbeat n'a pas été reçu depuis un moment T - défini par timeout (le délai d'inactivité) et max_tries (un nombre maximum de tentatives). Cela peut avoir à la base plusieurs raisons, par ex. dans un cluster donné A'B'C'D; C peut être rendu suspect si ( notez bien que A ping B, B ping C, C ping D et D ping A) :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2715
@@ -9002,7 +9010,7 @@
 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 ou C exécutent à 100% du CPU pour plus de T secondes. Donc, même si C envoie un ack heartbeat à B, B ne sera peut-être pas en mesure de le traiter car il est à 100%"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2720
@@ -9023,7 +9031,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 "Le réseau perd des paquets. Cela arrive normalement quand il y a trop de trafic sur le réseau, et le commutateur commence à larguer des paquets (normalement broadcasts tout d'abord, puis IP multicasts, et TCP packets pour terminer)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2735
@@ -9033,5 +9041,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 ou C sont entrain de traiter un callback. Disons que C a reçu un appel méthode distant sur son canal et qu'il prenne T+1 pour le traiter. Pendant ce temps, C ne traitera pas d'autres messages, y compris les heartbeats, et donc B ne recevra pas d'ack heartbeat et suspectera C."
 

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_JBoss_Cache_JGroups.po	2009-02-19 05:53:23 UTC (rev 84424)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_JBoss_Cache_JGroups.po	2009-02-19 06:13:49 UTC (rev 84425)
@@ -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-15 03:24+0000\n"
-"PO-Revision-Date: 2009-02-16 15:08+1000\n"
+"PO-Revision-Date: 2009-02-19 16:11+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -42,7 +42,7 @@
 "default MBean configurations. You only need to tweak them when you are "
 "deploying an application that has special network or performance "
 "requirements."
-msgstr "JBoss AS est accompagné d'un ensemble raisonnable de configurations par défaut de Beans JGroups et JBossCache. La plupart des applications sont juste 'prêtes à l'emploi' avec les configurations MBean par défaut. Vous avez juste besoin de les pofiner quand vous déployez une application liées à un réseau particulier ou qui est régie par des prérequis de performance particuliers."
+msgstr "JBoss AS est accompagné d'un ensemble raisonnable de configurations par défaut de Beans JGroups et JBossCache. La plupart des applications sont juste 'prêtes à l'emploi' avec les configurations MBean par défaut. Vous avez juste besoin de les ajuster quand vous déployez une application liées à un réseau particulier ou qui est régie par des prérequis de performance particuliers."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:15
@@ -79,7 +79,7 @@
 "configure the behavior and properties of each protocol in JGroups via those "
 "MBean attributes. Below is an example JGroups configuration in the "
 "<literal>ClusterPartition</literal> MBean."
-msgstr "Les configurations JGroups apparaîssent souvent en tant qu'attribut intégré dans les services MBean liés au cluster, comme l'attribut <literal>PartitionConfig</literal> dans le MBean <literal>ClusterPartition</literal> ou l'attribut <literal>ClusterConfig</literal> dans le MBean <literal>TreeCache</literal>. Vous pouvez configurer le comportement ou les propriétés de chaque protocole dans JGroups via ces attributs MBean. Voici ci-dessous un exemple de configuration JGroups dans le MBean <literal>ClusterPartition</literal>."
+msgstr "Les configurations JGroups apparaissent souvent en tant qu'attribut intégré dans les services MBean liés au cluster, comme l'attribut <literal>PartitionConfig</literal> dans le MBean <literal>ClusterPartition</literal> ou l'attribut <literal>ClusterConfig</literal> dans le MBean <literal>TreeCache</literal>. Vous pouvez configurer le comportement ou les propriétés de chaque protocole dans JGroups via ces attributs MBean. Voici ci-dessous un exemple de configuration JGroups dans le MBean <literal>ClusterPartition</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:32
@@ -278,7 +278,7 @@
 "is responsible for reading messages off the queue, doing whatever protocol-"
 "specific processing is required, and passing the message on to the next "
 "protocol in the stack."
-msgstr ""
+msgstr "<literal>down_thread</literal> indique si le protocole doit créer une file d'attente externe et un thread de traitement de file d'attente (également connu sous le nom de down_thread) pour les messages émanant de couches supérieures. La couche supérieure pourrait avoir un autre protocole, lui-même plus élevé dans la pile, ou l'application elle-même, si le protocole est en haut de la pile. Si true (par défaut), quand un message provient d'une couche supérieure, le thread d'appel place le message dans la file d'attente du protocole, et le retourne immédiatement. Le down_thread du protocole est chargé de lire des messages hors file d'attente, procédant au traitement spécifique-au-protocole requis, et passant le message au protocole suivant de la pile. "
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:47
@@ -287,21 +287,24 @@
 "<literal>up_thread</literal> is conceptually similar to down_thread, but "
 "here the queue and thread are for messages received from lower layers in the "
 "protocol stack."
-msgstr ""
+msgstr "<literal>up_thread</literal> est conçu selon un modèle similaire à down_thread, mais ici, la file d'attente et le thread sont pour les messages provenant des couches inférieures de la pile de protocoles."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:51
 #, no-c-format
+#, fuzzy
 msgid ""
 "Generally speaking, <literal>up_thread</literal> and <literal>down_thread</"
 "literal> should be set to false."
 msgstr ""
+"Normalement, <literal>up_thread</literal> et <literal>down_thread</"
+"literal> devraient être configurés à false."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:57
 #, no-c-format
 msgid "Transport Protocols"
-msgstr ""
+msgstr "Protocoles de transport"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:58
@@ -310,7 +313,7 @@
 "The transport protocols send messages from one cluster node to another "
 "(unicast) or from cluster node to all other nodes in the cluster (mcast). "
 "JGroups supports UDP, TCP, and TUNNEL as transport protocols."
-msgstr ""
+msgstr "Les protocoles de transport envoient des messages d'un noeud de cluster à un autre (unicast) ou bien d'un noeud de cluster vers tous les autres noeuds du cluste (mcast). JGroups supporte UDP, TCP et TUNNEL en tant que protocoles de transport."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:62
@@ -320,12 +323,14 @@
 "literal> elements are mutually exclusive. You can only have one transport "
 "protocol in each JGroups <literal>Config</literal> element"
 msgstr ""
+"Les éléments <literal>UDP</literal>, <literal>TCP</literal>, et <literal>TUNNEL</"
+"literal> sont exclusifs les uns des autres. Vous ne pouvez avoir qu'un seul protocole de transport pour chaque élément <literal>Config</literal> KGroups."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:67
 #, no-c-format
 msgid "UDP configuration"
-msgstr ""
+msgstr "Configuration UDP"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:68
@@ -336,7 +341,7 @@
 "protocol for your cluster service, you need to configure it in the "
 "<literal>UDP</literal> sub-element in the JGroups <literal>Config</literal> "
 "element. Here is an example."
-msgstr ""
+msgstr "UDP est le protocole préféré de JGroups. UDP utilise multicast ou des unicast multiples pour envoyer ou recevoir des messages. Si vous choisissez UDP comme protocole de transport pour votre service de cluster, vous aurez besoin de le configurer dans le sous-élément <literal>UDP</literal> de l'élément <literal>Config</literal>JGroups. En voici un exemple :"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:72
@@ -360,12 +365,29 @@
 "     ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
 " down_thread=\"false\" up_thread=\"false\"/>]]>"
 msgstr ""
+"<![CDATA[\n"
+"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\" \n"
+"     mcast_port=\"${jboss.hapartition.mcast_port:45566}\"\n"
+"     tos=\"8\"\n"
+"     ucast_recv_buf_size=\"20000000\"\n"
+"     ucast_send_buf_size=\"640000\"\n"
+"     mcast_recv_buf_size=\"25000000\"\n"
+"     mcast_send_buf_size=\"640000\"\n"
+"     loopback=\"false\"\n"
+"     discard_incompatible_packets=\"true\"\n"
+"     enable_bundling=\"false\"\n"
+"     max_bundle_size=\"64000\"\n"
+"     max_bundle_timeout=\"30\"\n"
+"     use_incoming_packet_handler=\"true\"\n"
+"     use_outgoing_packet_handler=\"false\"\n"
+"     ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:75
 #, no-c-format
 msgid "The available attributes in the above JGroups configuration are listed below."
-msgstr ""
+msgstr "Les attributs disponibles dans la configuration JGroups ci-dessus sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:78
@@ -375,7 +397,7 @@
 "IP multicasting. The default is <literal>true</literal>. If set to false, it "
 "will send n unicast packets rather than 1 multicast packet. Either way, "
 "packets are UDP datagrams."
-msgstr ""
+msgstr "<emphasis role=\"bold\">ip_mcast</emphasis> détermine si l'on doit utiliser IP multicasting ou non. La valeur par défaut est <literal>true</literal>. Si cette valeur est false, il enverra des packets n unicast à la place de packets 1 multicast. Dans tous les cas, les paquets sont des datagrammes UDP."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:83
@@ -384,7 +406,7 @@
 "<emphasis role=\"bold\">mcast_addr</emphasis> specifies the multicast "
 "address (class D) for joining a group (i.e., the cluster). If omitted, the "
 "default is <literal>228.8.8.8 </literal>."
-msgstr ""
+msgstr "<emphasis role=\"bold\">mcast_addr</emphasis> précise l'adresse multicast (class D) pour pouvoir joindre un groupe (c'est à dire, le cluster). En cas d'oubli, la valeur par défaut est <literal>228.8.8.8 </literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:88
@@ -392,7 +414,7 @@
 msgid ""
 "<emphasis role=\"bold\">mcast_port</emphasis> specifies the multicast port "
 "number. If omitted, the default is <literal>45566</literal>."
-msgstr ""
+msgstr "<emphasis role=\"bold\">mcast_port</emphasis>précise le numéro de port multicast. En cas d'oubli, la valeur par défaut est <literal>45566</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:92
@@ -406,6 +428,8 @@
 "setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr "
 "system property is set."
 msgstr ""
+"<emphasis role=\"bold\">bind_addr</emphasis> précise l'interface sur laquelle on peut recevoir et envoyer les multicasts (utiliser la propriété de système <literal>-Djgroups."
+"bind_address</literal>, si elle est présente). Si vous avez une machine multihomed, configurez la propriété du systèmeou l'attribut <literal>bind_addr</literal> à l'adresse NIC IP qui convient. Par défaut, la configuration de la propriété de système a priorité sur l'attribut XML à moins que la propriété de système -Djgroups.ignore.bind_addr ne soit configurée."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:95
@@ -417,6 +441,8 @@
 "literal> property for receiving multicasts. However, <literal>bind_addr</"
 "literal> (if set) is still used to send multicasts."
 msgstr ""
+"<emphasis role=\"bold\">receive_on_all_interfaces </emphasis> détermine si le noeud doit ou non écouter à toutes les interfaces pour les multicasts. La valeur par défaut est <literal>false</literal>. Elle prend précédent sur la propriété <literal>bind_addr</literal> pour la réception des multicasts. Cependant, <literal>bind_addr</"
+"literal> (si configurée) est toujours utilisée pour envoyer des multicasts."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:100
@@ -425,7 +451,7 @@
 "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> specifies whether "
 "this node send UDP packets via all the NICs if you have a multi NIC machine. "
 "This means that the same multicast message is sent N times, so use with care."
-msgstr ""
+msgstr "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> détermine si ce noeud envoie les packets UDP par tous les NIC, quand vous avez une machine NIC multiple. Cela signifie qu'un même message multicast est envoyé à N reprises, donc à utiliser avec précautions."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:105
@@ -437,6 +463,8 @@
 "addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</"
 "literal>\"."
 msgstr ""
+"<emphasis role=\"bold\">receive_interfaces</emphasis> précise une liste d'interfaces qui accueillent des multicasts. La connexion de réception de multicast écoutera toutes ces interfaces. C'est une liste séparée-par-virgule d'adresses IP ou de noms d'interfaces. Par exemple  \"<literal>192.168.5.1,eth1,127.0.0.1</"
+"literal>\"."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:111
@@ -447,7 +475,7 @@
 "but is actually something of a misnomer, since the value here refers to how "
 "many network hops a packet will be allowed to travel before networking "
 "equipment will drop it."
-msgstr ""
+msgstr "<emphasis role=\"bold\">ip_ttl</emphasis> précise la durée de vir (time-to-live) des packets Multicast IP. TTL est une terme communément utilisé en réseautage multicast, mais cette appellation trompeuse, puisque la valeur ici fait référence aux nombres de sauts entre les serveurs autorisés avant que l\"équipement de réseau abandonne le paquet."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:115
@@ -459,7 +487,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> précise si vous devez utiliser un thread séparé pour traiter les messages qui arrivent. Parfois, les récepteurs sont débordés (ils doivent gérer la dé-sérialisation etc.) Le gestionnaire de paquet est un thread séparé qui s'occupe de la dé-sérialisation, le thread-récepteur s'occupe simplement de mettre le paquet dans la file d'attente et de le retourner immédiatement. Paramétrer cela à 'true' ajoute un thread supplémentaire. La valeur par défaut est <literal>true</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:118
@@ -468,7 +496,7 @@
 "<emphasis role=\"bold\">use_outgoing_packet_handler</emphasis> specifies "
 "whether to use a separate thread to process outgoing messages. The default "
 "is false."
-msgstr ""
+msgstr "<emphasis role=\"bold\">use_outgoing_packet_handler</emphasis> précise si on doit utiliser un thread séparé pour traiter les messages sortants. La valeur par défaut est 'false'."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:121
@@ -481,7 +509,7 @@
 "elapsed, whichever occurs first. Then bundle queued messages into a large "
 "message and send it. The messages are unbundled at the receiver. The default "
 "is <literal>false</literal>."
-msgstr ""
+msgstr "<emphasis role=\"bold\">enable_bundling</emphasis> détermine si on doit activer le groupage des messages. S'il est sur <literal>true</literal>, le noeud placerait des messages sortant sur la file d'attente jusqu'à ce qu\"on ait accumulé <literal>max_bundle_size</literal> d'octets. ou que <literal>max_bundle_size</literal> de millesecondes se soient écoulées, l'un ou l'autre en premier. Puis regrouper les messages de file d'attente en plus grand messages et les envoyer. Les messages sont ne non pas groupés au niveau de récepteur. La valeur par défaut est <literal>max_bundle_size</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:129
@@ -491,7 +519,7 @@
 "outgoing message back up the stack. In <literal>unicast</literal> mode, the "
 "messages are sent to self. In <literal>mcast</literal> mode, a copy of the "
 "mcast message is sent. The default is <literal>false</literal>"
-msgstr ""
+msgstr "<emphasis role=\"bold\">loopback</emphasis>précise si le message de sortie en boucle sauvegarde la pile. En mode <literal>unicast</literal>, les messages sont renvoyés. En mode <literal>mcast</literal>, une copie du message mcast est envoyée. Dans <literal>mcast</literal>, une copie du mcast messages est envoyée. La valeur par défaut est <literal>false</literal>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:134
@@ -503,7 +531,7 @@
 "different version of JGroups is received, it will be discarded if set to "
 "true, otherwise a warning will be logged. The default is <literal>false</"
 "literal>"
-msgstr ""
+msgstr "<emphasis role=\"bold\">discard_incompatibe_packets</emphasis> détermine si on doit exclure les paquets issus de versions différentes de JGroups. Chaque message du cluster est taggé d'une version JGroups. Quand on reçoit un message d'une version différente de JGroups, il sera ignoré si paramétré à true, ou bien un avertissement sera enregistré. La valeur par défaut est <literal>false</literal>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:140
@@ -514,6 +542,8 @@
 "buffer sizes. It is good to have a large receiver buffer size, so packets "
 "are less likely to get dropped due to buffer overflow."
 msgstr ""
+"<emphasis role=\"bold\">mcast_send_buf_size, mcast_recv_buf_size, "
+"ucast_send_buf_size, ucast_recv_buf_size</emphasis> détermine les taille des mémoires tampons pour recevoir et envoyer. Il est bon d'avoir une taille élevée de mémoire tampon pour la réception, afin que les paquets soient moins enclins à être rejetés compte tenu de la surcharge de mémoire tampon."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:146
@@ -521,7 +551,7 @@
 msgid ""
 "<literal>tos</literal> specifies traffic class for sending unicast and "
 "multicast datagrams."
-msgstr ""
+msgstr "<literal>tos</literal> précise la classe de trafic pour envoyer des datagrammes unicast et multicast."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:152
@@ -549,7 +579,7 @@
 "protocol, you should define a <literal>TCP</literal> element in the JGroups "
 "<literal>Config</literal> element. Here is an example of the <literal>TCP</"
 "literal> element."
-msgstr ""
+msgstr "SInon, un cluster basé-JGroups peut également opérer sur des connexions TCP. Par rapport à UDP, TCP génère plus de trafic de réseau quand la taille du cluster augmente. TCP est fondamentalement un protocole TCP multiple. Pour utiliser les messages multicast, JGroups utilise les unicasts TCP. Pour utiliser TCP en tant que protocole de transport, vous devrez définir un élément <literal>TCP</literal> dans l'élément <literal>Config</literal>. Voici un exemple de l'élément <literal>TCP</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:167
@@ -560,12 +590,16 @@
 "    loopback=\"true\"\n"
 "    down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;TCP start_port=\"7800\"\n"
+"    bind_addr=\"192.168.5.1\"\n"
+"    loopback=\"true\"\n"
+"    down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:168
 #, no-c-format
 msgid "Below are the attributes available in the <literal>TCP</literal> element."
-msgstr ""
+msgstr "Voici ci-dessous les attributs disponibles dans l'élément <literal>TCP</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:171
@@ -593,6 +627,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> détermine la capacité des ports TCP auxquels les serveur devrait se relier. La connexion logicielle du serveur est liée au premier port disponible de <literal>start_port</literal>. Si aucun port n'est disponible (par ex. à cause du pare-feu) avant le <literal>end_port</literal>, "
+"alors le serveur renverra une exception. Si aucun <literal>end_port</literal> ou <literal>end_port &lt; start_port</literal> n'est fourni <literal>start_port == end_port</literal>, alors il n'y a pas de limite supérieure à la capacité portaire. Si <literal>start_port == end_port</literal>, alors, nous forçons JGroups à utiliser le port donné (le démarrage échoue si le port n'est pas disponible). La valeur par défaut est de 7800. Avec le paramètre 0, le système d'exploitation choisira un port. Veuillez garder à l'esprit que paramètrer à 0 ne fonctionnera seulement que si on utilise MPING ou TCPGOSSIP en tant que protocoles discovery car <literal>TCCPING</literal> a besoin de lister les noeuds et leurs ports correspondants."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:182
@@ -602,7 +638,7 @@
 "outgoing message back up the stack. In <literal>unicast</literal> mode, the "
 "messages are sent to self. In <literal>mcast</literal> mode, a copy of the "
 "mcast message is sent. The default is false."
-msgstr ""
+msgstr "<emphasis role=\"bold\">loopback</emphasis>précise si le message de sortie doit être retourné en boucle vers la pile. En mode <literal>unicast</literal>, les messages sont renvoyés. En mode <literal>mcast</literal>, une copie du mcast message est envoyée. La valeur par défaut est <literal>false</literal>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:187
@@ -611,7 +647,7 @@
 "<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> define "
 "receive and send buffer sizes. It is good to have a large receiver buffer "
 "size, so packets are less likely to get dropped due to buffer overflow."
-msgstr ""
+msgstr "<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> détermine les tailles des mémoires tampons pour recevoir et envoyer. Il est bon d'avoir une grande taille de mémoire tampons pour recevoir, pour que les paquets soient moins susceptibles d'être rejetés à cause de la surcharge de la mémoire tampon."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:190
@@ -620,7 +656,7 @@
 "<emphasis role=\"bold\">conn_expire_time</emphasis> specifies the time (in "
 "milliseconds) after which a connection can be closed by the reaper if no "
 "traffic has been received."
-msgstr ""
+msgstr "<emphasis role=\"bold\">conn_expire_time</emphasis> précise la durée (en millesecondes) sans trafic, après laquelle une connexion pourra être fermée par un reaper."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:195
@@ -631,6 +667,8 @@
 "done. If either value is &gt; 0, reaping will be enabled. By default, "
 "reaper_interval is 0, which means no reaper."
 msgstr ""
+"<emphasis role=\"bold\">reaper_interval</emphasis> précise l'intervalle (en "
+"millesecondes) d'exécution du reaper. Si les deux valeurs sont 0, il n'y aura pas de reaping. SI la valeur est &gt; 0, reaping sera activé. Par défaut, l'interval_reaper est de 0, c'est à dire pas de reaper."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:200
@@ -640,7 +678,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> précise le maximum de temps (en millesecondes) pour la création d'une connexion logicielle. Lorsqu'on fait le découverte initiale, et qu'un homologue attend, n'attendez pas indéfiniement, mais continuer après le délai de timeout pour sonder les autres membres par ping."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:203
@@ -649,7 +687,7 @@
 "<emphasis role=\"bold\">use_send_queues</emphasis> specifies whether to use "
 "separate send queues for each connection. This prevents blocking on write if "
 "the peer hangs. The default is true."
-msgstr ""
+msgstr "<emphasis role=\"bold\">use_send_queues</emphasis> précise si on doit ou non utiliser des files d'attente d'envois séparées pour chaque connexion. Cela empêche de bloquer 'écriture' si l'homologue est en attente. La valeur par défaut est true."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:206
@@ -667,7 +705,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> précise l'adresse IP extérieure pour diffuser à d'autres membres du groupe (si différente de l'adresse locale). Cela est utile quand vous avez utilisé NAT (Network Address Translation), comme par exemple un noeud sur un réseau privé, derrière un parefeu, mais que vous ne pourrez y aller que par une adresse externe invisible, qui est différente de l'adresse locale à laquelle il est affilié. Ainsi, le noeud peut être configuré pour diffuser son adresse externe, tout en étant en mesure de se rattacher à son adresse locale. Cela évite d'avoir à utiliser le protocole TUNNEL, (et donc un prérequis pour le router central gossip) car les noeuds en dehors du parefeu, peuvent toujours mener au noeud à l'intérieur du parefeu, mais uniquement vers son adresse externe. Sans configurer l'external_addr, le noeud qui se trouve derrière le parefeu va diffuser son adresse privée aux autres noeuds qui ne pourront p!
 as y parvenir."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:209
@@ -676,7 +714,7 @@
 "<emphasis role=\"bold\">skip_suspected_members</emphasis> specifies whether "
 "unicast messages should not be sent to suspected members. The default is "
 "true."
-msgstr ""
+msgstr "<emphasis role=\"bold\">skip_suspected_members</emphasis> détermine si les messages unicast doivent être envoyés à des membres suspects. La valeur par défaut est true."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:212
@@ -689,13 +727,13 @@
 "(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> détermine TCP_NODELAY. TCP 'nagle' les messages par défaut, c'est à dire que, conceptuellement, les petits messages sont réunis dans de plus gros messages. Si vous souhaitez invoquer des appels de méthode de cluster synchronisées, vous devrez désactiver 'nagling' en plus de désactiver le regroupement de messages (en paramétrant <literal>tcp_nodelay</literal> à true. La valeur par défaut est false."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:220
 #, no-c-format
 msgid "TUNNEL configuration"
-msgstr ""
+msgstr "Configuration de TUNNEL"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:221
@@ -712,7 +750,7 @@
 "connection to a host inside the firewall. The TUNNEL configuration is "
 "defined in the TUNNEL element in the JGroups Config element. Here is an "
 "example.."
-msgstr ""
+msgstr "Le protocole TUNNEL utilise un router externe pour envoyer des messages. Le router externe est connu sous le nom de <literal>GossipRouter</literal>. Chaque noeud doit enregistrer un router. Tous les messages sont envoyés au router et redirigés vers leur destination. L'approche TUNNEL peut être utilisée pour mettre en place une communication avec les noeuds en arrière plan des parefeux. Un noeud peut établir une connexion TCP vers le GossipRouter à travers le parefeu (vous pouvez utiliser port 80). La même connexion est utilisée par le router pour envoyer des messages vers des noeuds situés derrière le parefeu puisque la plupart des parefeux n'autorisent pas les hôtes externes d'initier une connexion TCP vers un hôte dans l'enceinte du parefeu. La configuration TUNNEL est définie dans l'élément TUNNEL, lui-même dans l'élément JGroups Config. En voici un exemple ..."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:226
@@ -722,6 +760,9 @@
 "    router_host=\"192.168.5.1\"\n"
 "    down_thread=\"false\" up_thread=\"false/&gt;"
 msgstr ""
+"&lt;TUNNEL router_port=\"12001\"\n"
+"    router_host=\"192.168.5.1\"\n"
+"    down_thread=\"false\" up_thread=\"false/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:229
@@ -729,7 +770,7 @@
 msgid ""
 "The available attributes in the <literal>TUNNEL</literal> element are listed "
 "below."
-msgstr ""
+msgstr "Les attributs disponibles dans l'élément <literal>TUNNEL</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:232
@@ -737,7 +778,7 @@
 msgid ""
 "<emphasis role=\"bold\">router_host</emphasis> specifies the host on which "
 "the GossipRouter is running."
-msgstr ""
+msgstr "<emphasis role=\"bold\">router_host</emphasis> détermine l'hôte sur lequel le GossipRouter est exécuté."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:236
@@ -745,7 +786,7 @@
 msgid ""
 "<emphasis role=\"bold\">router_port</emphasis> specifies the port on which "
 "the GossipRouter is listening."
-msgstr ""
+msgstr "<emphasis role=\"bold\">router_port</emphasis> détermine le port qu'écoute le GossipRouter."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:240
@@ -753,13 +794,13 @@
 msgid ""
 "<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop "
 "messages back up the stack. The default is <literal>true</literal>."
-msgstr ""
+msgstr "<emphasis role=\"bold\">loopback</emphasis> détermine si on doit renvoyer les messages en boucle vers la pile. La valeur par défaut est <literal>true</literal>."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:251
 #, no-c-format
 msgid "Discovery Protocols"
-msgstr ""
+msgstr "Protocoles Discovery"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:252
@@ -774,6 +815,8 @@
 "group membership protocol (GMS, see <xref linkend=\"jbosscache-jgroups-other-"
 "gms\"/>) admits it into the group."
 msgstr ""
+"Le cluster a besoin de maintenir une liste des noeuds membres courants de façon à ce que l'équilibreur des charges et l'intercepteur de client sache comment diriger leurs requêtes. Les protocoles Discovery sont utilisés pour découvrir les noeuds du cluster et détecter le membre le plus ancien du cluster, c'est à dire le coordinateur. Tous les noeuds initiaux sont découverts au démarrage du cluster. Quand un nouveau noeud rejoint le cluster plus tard, il n'est découvert qu'après que le protocole d'appartenance au groupe (GMS de l'anglais Group Membership Protocol, voir <xref linkend=\"jbosscache-jgroups-other-"
+"gms\"/> ) l'admette dans le groupe."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:256
@@ -783,13 +826,13 @@
 "choose to use different discovery protocols based on your transport "
 "protocol. These are also configured as sub-elements in the JGroups MBean "
 "<literal>Config</literal> element."
-msgstr ""
+msgstr "Comme les protocoles discovery sont situés au dessus du protocole de transport, vous pouvez choisir d'utiliser des protocoles discover différents, basés sur votre protocole de transport. Ils sont également configurés en tant que sous-éléments de l'élément JGroups MBean <literal>Config</literal>."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:262
 #, no-c-format
 msgid "PING"
-msgstr ""
+msgstr "PING"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:263
@@ -803,13 +846,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 "PNG est un protocole discovery qui fonctionne soit en diffusant multiple requêtes PING vers une adresse IP multicast, ou bien en se connectant à un router gossip. Ainsi, PING est normalement situé au dessus des protocoles de transport TUNNEL ou UDP. Chaque noeud répond avec un paquet {C, A}, pour lequel C= l'adresse du coordinateur et A= sa propre adresse. Après avoir obtenu une réponse de timeout milleseconds ou de num_initial_members, le nouveau venu détermine le coordinateur à partir des réponses, et envoie lui une requête JOINTE. Si personne ne répond, on assume que nous sommes les premiers membres d'un groupe."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:266
 #, no-c-format
 msgid "Here is an example PING configuration for IP multicast."
-msgstr ""
+msgstr "Voici un exemple de configuration PING pour IP multicast."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:270
@@ -819,12 +862,15 @@
 "    num_initial_members=\"2\"\n"
 "    down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;PING timeout=\"2000\"\n"
+"    num_initial_members=\"2\"\n"
+"    down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:271
 #, no-c-format
 msgid "Here is another example PING configuration for contacting a Gossip Router."
-msgstr ""
+msgstr "Voici un autre exemple de configuration PING pour contacter un Router Gossip."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:273
@@ -837,6 +883,12 @@
 "              num_initial_members=\"3\"\n"
 "              down_thread=\"false\" up_thread=\"false\"/>]]>"
 msgstr ""
+"<![CDATA[        \n"
+"<PING gossip_host=\"localhost\"\n"
+"      gossip_port=\"1234\"\n"
+"              timeout=\"3000\" \n"
+"              num_initial_members=\"3\"\n"
+"              down_thread=\"false\" up_thread=\"false\"/>]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:278
@@ -844,7 +896,7 @@
 msgid ""
 "The available attributes in the <literal>PING</literal> element are listed "
 "below."
-msgstr ""
+msgstr "Les attributs disponibles de l'élément <literal>PING</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:281
@@ -855,7 +907,7 @@
 msgid ""
 "<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of "
 "milliseconds to wait for any responses. The default is 3000."
-msgstr ""
+msgstr "<emphasis role=\"bold\">timeout</emphasis> précise le nombre maximum de millesecondes qu'il faut attendre pour une réponse. La valeur par défaut est 3000."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:285
@@ -865,7 +917,7 @@
 msgid ""
 "<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum "
 "number of responses to wait for unless timeout has expired. The default is 2."
-msgstr ""
+msgstr "<emphasis role=\"bold\">num_initial_members</emphasis> détermine le nombre maximum de réponses qu'il faut attendre à moins que le délai d'inactivité ne soit écoulé. La valeur par défaut est 2."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:289
@@ -873,7 +925,7 @@
 msgid ""
 "<emphasis role=\"bold\">gossip_host</emphasis> specifies the host on which "
 "the GossipRouter is running."
-msgstr ""
+msgstr "<emphasis role=\"bold\">gossip_host</emphasis> détermine l'hôte sur lequel GossipRouter est exécuté."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:293
@@ -881,7 +933,7 @@
 msgid ""
 "<emphasis role=\"bold\">gossip_port</emphasis> specifies the port on which "
 "the GossipRouter is listening on."
-msgstr ""
+msgstr "<emphasis role=\"bold\">gossip_port</emphasis> détermine le port qu'écoute GossipRouter."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:297
@@ -889,7 +941,7 @@
 msgid ""
 "<emphasis role=\"bold\">gossip_refresh</emphasis> specifies the interval (in "
 "milliseconds) for the lease from the GossipRouter. The default is 20000."
-msgstr ""
+msgstr "<emphasis role=\"bold\">gossip_refresh</emphasis> détermine l'intervalle (en millesecondes) pour le lease de GossipRouter. La valeur par défaut est de 20000."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:301
@@ -898,7 +950,7 @@
 "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
 "of addresses (e.g., <literal>host1[12345],host2[23456]</literal>), which are "
 "pinged for discovery."
-msgstr ""
+msgstr "<emphasis role=\"bold\">initial_hosts</emphasis> est une liste d'adresses séparées par des virgules (comme par exemple, <literal>host1[12345],host2[23456]</literal>), qui sont pinguées pour discovery."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:306
@@ -923,7 +975,7 @@
 "The discovery phase returns when the <literal>timeout</literal> ms have "
 "elapsed or the <literal>num_initial_members</literal> responses have been "
 "received."
-msgstr ""
+msgstr "La phase discovery retourne quand le <literal>timeout</literal> en ms, s'est écoulé, ou bien quand les réponses <literal>num_initial_members</literal> ont été reçues."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:319
@@ -940,7 +992,7 @@
 "<literal>gossip_host</literal> and <literal>gossip_port</literal> "
 "attributes. It works on top of both UDP and TCP transport protocols. Here is "
 "an example."
-msgstr ""
+msgstr "Le protocole TCPGOSSIP ne fonctionne qu'avec le GossipRouter. Il fonctionne essentiellement de la même façon que la configuration de protocole PING avec des attributs valides <literal>gossip_host</literal> et <literal>gossip_port</literal>. Il fonctionne au dessus des protocoles de transport UDP et TCP. En voici un exemple."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:323
@@ -964,7 +1016,7 @@
 msgid ""
 "The available attributes in the <literal>TCPGOSSIP</literal> element are "
 "listed below."
-msgstr ""
+msgstr "Les attributs disponibles dans l'élément <literal>TCPGOSSIP</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:337
@@ -973,13 +1025,13 @@
 "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
 "of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for "
 "GossipRouters to register with."
-msgstr ""
+msgstr "<emphasis role=\"bold\">initial_hosts</emphasis> est une liste d'adresses séparées par des virgules (comme par exemple, <literal>host1[12345],host2[23456]</literal>), à enregistrer par GossipRouters."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:347
 #, no-c-format
 msgid "TCPPING"
-msgstr ""
+msgstr "TCPPING"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:348
@@ -989,7 +1041,7 @@
 "discovery. This is essentially a static configuration. It works on top of "
 "TCP. Here is an example of the <literal>TCPPING</literal> configuration "
 "element in the JGroups <literal>Config</literal> element."
-msgstr ""
+msgstr "Le protocole TCPPING prend un ensemble de membres connus et les pingue pour discovery. Il s'agit essentiellement d'une configuration statique qui fonctionne au dessus de TCP. Voici un exemple de l'élément de configuration <literal>TCPPING</literal> dans l'élément JGoups <literal>Config</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:352
@@ -1001,6 +1053,11 @@
 "        num_initial_members=\"3\"\n"
 "         down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;TCPPING timeout=\"2000\"\n"
+"        initial_hosts=\"hosta[2300],hostb[3400],hostc[4500]\"\n"
+"        port_range=\"3\"\n"
+"        num_initial_members=\"3\"\n"
+"         down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:355
@@ -1008,7 +1065,7 @@
 msgid ""
 "The available attributes in the <literal>TCPPING</literal> element are "
 "listed below."
-msgstr ""
+msgstr "Les attributs disponibles dans l'élément <literal>TCPPING</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:366
@@ -1017,7 +1074,7 @@
 "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
 "of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for "
 "pinging."
-msgstr ""
+msgstr "<emphasis role=\"bold\">initial_hosts</emphasis> est une liste d'adresses séparées par des virgules (comme par exemple, <literal>host1[12345],host2[23456]</literal>), à pinguer."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:370
@@ -1031,12 +1088,14 @@
 "hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options "
 "allows for multiple nodes on the same host to be pinged."
 msgstr ""
+"<emphasis role=\"bold\">port_range</emphasis> détermine le nombre de ports consécutifs qu'il faut sonder au départ quand on veut obtenir une affiliation, en commençant par le port précisé dans le paramètre initial_host. Compte tenues des valeurs actuelles de port_range et d'initial_hosts ci-dessus, la couche TCPPING essaiera de se connecter à hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, "
+"hostb:3402, hostc:4500, hostc:4501, hostc:4502. Les options de configuration permettent à plusieurs noeuds d'être pingués sur le même hôte."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:381
 #, no-c-format
 msgid "MPING"
-msgstr ""
+msgstr "MPING"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:382
@@ -1049,7 +1108,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 utilise IP multicast pour découvrir l'affiliation initiale. Cela peut être utilisé avec tous les transports, mais c'est normalement utilisé en combinaison avec TCP. TCP a normalement besoin de TCPPING, qui doit lister tous les membres du groupe explicitement, mais MPING n'est pas lié à cette exigence. Le cas d'utilisation typique, c'est quand on souhaite avoir TCP comme transport, mais multicast pour discovery, de façon à ce qu'on n'ait pas à définir la liste statique d'hôtes initiaux dans TCPPING, ni besoin de Router Gossip externe."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:386
@@ -1063,6 +1122,13 @@
 "    num_initial_members=\"3\"\n"
 "    down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;MPING timeout=\"2000\"\n"
+"    bind_to_all_interfaces=\"true\"\n"
+"    mcast_addr=\"228.8.8.8\"\n"
+"    mcast_port=\"7500\"\n"
+"    ip_ttl=\"8\"\n"
+"    num_initial_members=\"3\"\n"
+"    down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:389
@@ -1070,7 +1136,7 @@
 msgid ""
 "The available attributes in the <literal>MPING</literal> element are listed "
 "below."
-msgstr ""
+msgstr "Les attributs disponibles dans l'élément <literal>MPING</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:396
@@ -1079,7 +1145,7 @@
 "<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum "
 "number of responses to wait for unless timeout has expired. The default is "
 "2.."
-msgstr ""
+msgstr "<emphasis role=\"bold\">num_initial_members</emphasis> détermine le nombre maximum de réponses qu'il faut attendre à moins que le délai d'inactivité ne se soit écoulé. La valeur par défaut est de 2."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:400
@@ -1087,7 +1153,7 @@
 msgid ""
 "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on "
 "which to send and receive multicast packets."
-msgstr ""
+msgstr "<emphasis role=\"bold\">bind_addr</emphasis> détermine l'interface sur laquelle envoyer et recevoir les paquets multicast."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:404
@@ -1096,6 +1162,8 @@
 "<emphasis role=\"bold\">bind_to_all_interfaces</emphasis> overrides the "
 "<literal>bind_addr</literal> and uses all interfaces in multihome nodes."
 msgstr ""
+"<emphasis role=\"bold\">bind_to_all_interfaces</emphasis> remplace "
+"<literal>bind_addr</literal> et utilise toutes les interfaces de noeuds multihome."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:408
@@ -1103,13 +1171,13 @@
 msgid ""
 "<emphasis role=\"bold\">mcast_addr, mcast_port, ip_ttl</emphasis> attributes "
 "are the same as related attributes in the UDP protocol configuration."
-msgstr ""
+msgstr "Les attributs <emphasis role=\"bold\">mcast_addr, mcast_port, ip_ttl</emphasis> sont les mêmes que les attributs relatifs de la configuration de protocole UDP."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:418
 #, no-c-format
 msgid "Failure Detection Protocols"
-msgstr ""
+msgstr "Protocoles de détection de défaillance"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:419
@@ -1121,13 +1189,13 @@
 "the load balancer and client interceptors know to avoid the dead node. The "
 "failure detection protocols are configured as sub-elements in the JGroups "
 "MBean <literal>Config</literal> element."
-msgstr ""
+msgstr "Les protocole de détection de défaillance sont utilisés pour détecter les noeuds défectueux. Une fois qu'un noeud est détecté, une phase de vérification de suspect peut avoir lieu, suite à laquelle, si le noeud est encore considéré comme inactif, le cluster mettra à jour ses vues, de façon à ce que l'équilibreur des charges et les intercepteurs de clients puissent éviter le noeud mort. Les protocoles de détection de défaillance sont configurés en tant que sous-éléments de l'élément <literal>Config</literal>JGroups MBean."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:425
 #, no-c-format
 msgid "<title>FD</title>"
-msgstr ""
+msgstr "<title>FD</title>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:426
@@ -1140,7 +1208,7 @@
 "double check whether the suspected node is indeed dead after which, if the "
 "node is still considered dead, updates the cluster's view. Here is an "
 "example FD configuration."
-msgstr ""
+msgstr "FD est un protocole de détection de défaillance, basé sur les messages heartbeat. Ce protocole exige que chaque noeud envoie régulièrement des messages are-you-alive (êtes-vous-vivants) à ses voisins. Si le voisin ne répond pas, le noeud appelant envoie un message SUSPECT vers le cluster. Le coordinateur de groupe actuel peut vérifier optionnellement par deux fois si le noeud suspecté est bien inactif, dans lequel cas, si le noeud est toujours considéré inactif, il met à jour la vue du cluster. Voici un exemple de configuration FD."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:430
@@ -1151,6 +1219,10 @@
 "    shun=\"true\"\n"
 "    down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;FD timeout=\"2000\"\n"
+"    max_tries=\"3\"\n"
+"    shun=\"true\"\n"
+"    down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:433
@@ -1158,7 +1230,7 @@
 msgid ""
 "The available attributes in the <literal>FD</literal> element are listed "
 "below."
-msgstr ""
+msgstr "Les attributs disponibles de l'élément <literal>FD</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:436
@@ -1167,7 +1239,7 @@
 "<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of "
 "milliseconds to wait for the responses to the are-you-alive messages. The "
 "default is 3000."
-msgstr ""
+msgstr "<emphasis role=\"bold\">timeout</emphasis> détermine le nombre maximum de millesecondes qu'il faut attendre pour les réponses des messages are-you-alive. La valeur par défaut est 3000."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:440
@@ -1176,7 +1248,7 @@
 "<emphasis role=\"bold\">max_tries</emphasis> specifies the number of missed "
 "are-you-alive messages from a node before the node is suspected. The default "
 "is 2."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_tries</emphasis> détermine le nombre de messages are-you-alive manqués émis à partir d'un noeud avant que ce noeud soit suspecté. La valeur par défaut est de 2."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:444
@@ -1188,7 +1260,7 @@
 "through the discovery process. JGroups allows to configure itself such that "
 "shunning leads to automatic rejoins and state transfer, which is the default "
 "behaivour within JBoss Application Server."
-msgstr ""
+msgstr "<emphasis role=\"bold\">shun</emphasis> détermine si un noeud défaillant doit être exclus. Une fois évincé, le noeud sera exclus du cluster même s'il revient plus tard. Le noeud exclus devra rejoindre le cluster par le processus discovery. JGroups permet la self-configuration, de manière à ce que les leads exclus soient automatiquement rejoints et opèrent les transferts d'état, ce qui constitue le comportement par défaut de JBoss Application Server."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:450
@@ -1197,13 +1269,13 @@
 "Regular traffic from a node counts as if it is a live. So, the are-you-alive "
 "messages are only sent when there is no regular traffic to the node for "
 "sometime."
-msgstr ""
+msgstr "Un trafic régulier qui part d'un noeud est un indicateur qu'il est actif. Donc, les messages are-you-alive ne sont envoyés que s'il n'y a pas de trafic régulier en direction du noeud pendant un certain temps."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:459
 #, no-c-format
 msgid "FD_SOCK"
-msgstr ""
+msgstr "FD_SOCK"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:460
@@ -1218,13 +1290,13 @@
 "suspected. The simplest FD_SOCK configuration does not take any attribute. "
 "You can just declare an empty <literal>FD_SOCK</literal> element in "
 "JGroups's <literal>Config</literal> element."
-msgstr ""
+msgstr "FD_SOCK est un protocole de détection de défaillance, basé sur un cercle de connexions TCP, créé entre les membres du groupe. Chaque membre d'un groupe donné, se connecte à son voisin (le dernier membre se connecte en premier) formant ainsi un cercle. Membre B est suspecté quand son voisin A détecte une connexion logicielle TCP anormalement rapproché (certainement lié à un plantage de noeud). Cependant, si un membre B est sur le point de partir gracieusement, il l'indique à son voisin A, de façon à ce qu'il ne devienne pas suspect à son tour. La configuration FD_SOCK la plus simple, ne prend aucun attribut. Vous n'avez qu'à déclarer un élément <literal>FD_SOCK</literal> comme vide dans l'élément JGroup <literal>Config</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:464
 #, no-c-format
 msgid "&lt;FD_SOCK_down_thread=\"false\" up_thread=\"false\"/&gt;"
-msgstr ""
+msgstr "&lt;FD_SOCK_down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:466
@@ -1232,7 +1304,7 @@
 msgid ""
 "There available attributes in the <literal>FD_SOCK</literal> element are "
 "listed below."
-msgstr ""
+msgstr "Les attributs disponibles dans l'élément <literal>FD_SOCK</literal> sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:469
@@ -1242,13 +1314,13 @@
 "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 ""
+msgstr "<emphasis role=\"bold\">bind_addr</emphasis> détermine l'interface à laquelle la connexion logicielle du serveur doit se lier. Si la propriété de système -Djgroups.ignore.bind_address est déterminée, la valeur XML pourra être ignorée. Ce comportement pourra être inversé en paramétrant la propriété de système -Djgroups.ignore.bind_addr=true."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:477
 #, no-c-format
 msgid "VERIFY_SUSPECT"
-msgstr ""
+msgstr "VERIFY_SUSPECT"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:478
@@ -1259,7 +1331,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 "Le protocole vérifie si un  membre suspect est vraiment inactif en pinguant ce membre une dernière fois. Cette vérification est réalisée par le coordinateur du cluster. Le membre suspecté est abandonné par le groupe du cluster s'il est confirmé mort. Le but de ce protocole est de minimiser les faux soupçons. Voici un exemple :"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:482
@@ -1269,12 +1341,15 @@
 "<VERIFY_SUSPECT timeout=\"1500\"\n"
 "        down_thread=\"false\" up_thread=\"false\"/>]]>"
 msgstr ""
+"<![CDATA[                        \n"
+"<VERIFY_SUSPECT timeout=\"1500\"\n"
+"        down_thread=\"false\" up_thread=\"false\"/>]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:484
 #, no-c-format
 msgid "The available attributes in the FD_SOCK element are listed below."
-msgstr ""
+msgstr "Les attributs disponibles de l'élément FD_SOCK sont listés ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:489
@@ -1282,13 +1357,13 @@
 msgid ""
 "timeout specifies how long to wait for a response from the suspected member "
 "before considering it dead."
-msgstr ""
+msgstr "timeout détermine combien de temps doit-on attendre une réponse d'un membre suspect avant de le considérer comme mort."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:500
 #, no-c-format
 msgid "FD versus FD_SOCK"
-msgstr ""
+msgstr "FD versus FD_SOCK"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:501
@@ -1297,25 +1372,25 @@
 "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 et FD_SOCK, chacun pris individuellement, ne représentent pas une couche de détection de défaillance solide, Penchons-nous sur les différences entre ces protocoles de détection de défaillance pour bien comprendre comment ils se complémentent les uns les autres :"
 
 #. Tag: emphasis
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:505
 #, no-c-format
 msgid "<emphasis>FD</emphasis>"
-msgstr ""
+msgstr "<emphasis>FD</emphasis>"
 
 #. Tag: para
 #: 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 "Une machine surchargée pourrait être un peu lente pour envoyer des réponses aux messages 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 membre sera considéré suspect lorsqu'il est suspendu d'un débogueur/profiler."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:520
@@ -1323,19 +1398,19 @@
 msgid ""
 "Low timeouts lead to higher probability of false suspicions and higher "
 "network traffic."
-msgstr ""
+msgstr "Les faibles timeouts mènent à une plus grande probabilité de faux soupçons et à un trafic de réseau plus élevé."
 
 #. 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 "Les timeouts élevés ne détecteront pas, ni ne retirerons les membres plantés avant un bon moment."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:532
 #, no-c-format
 msgid "<emphasis>FD_SOCK</emphasis>:"
-msgstr ""
+msgstr "<emphasis>FD_SOCK</emphasis>:"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:538
@@ -1343,25 +1418,25 @@
 msgid ""
 "Suspended in a debugger is no problem because the TCP connection is still "
 "open."
-msgstr ""
+msgstr "Etre suspendu dans un débogueur n'est pas vraiment un problème car la connexion TCP est toujours ouverte."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:543
 #, no-c-format
 msgid "High load no problem either for the same reason."
-msgstr ""
+msgstr "Les hauts volumes ne constituent pas un problème non plus, et ce pour les mêmes raisons."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:548
 #, no-c-format
 msgid "Members will only be suspected when TCP connection breaks"
-msgstr ""
+msgstr "Les membres ne seront suspectés que lorsque la connexion TCP est rompue"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:557
 #, no-c-format
 msgid "So hung members will not be detected."
-msgstr ""
+msgstr "Donc les membres bloqués ne seront pas détectés."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:562
@@ -1370,7 +1445,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 "Aussi, un commutateur défaillant ne pourra pas être détecté à  moins qu'une connexion ne soit exécutée dans un timeout TCP (entre 2-20 minutes, suivant l'implémentation de la pile TCP/IP)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:569
@@ -1378,7 +1453,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 "Le but d'une couche de détection de défaillance est de reporter les véritable échecs et donc d'éviter les faux soupçons. Deux solutions se présentent :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:574
@@ -1393,7 +1468,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 "Par défaut, JGroups configure la connexion logicielle FD_SOCK par KEPP_ALIVE, ce qui signifie que TCP envoie un heartbeat sur la connexion sur laquelle aucun trafic n'a été enregistré au cours des 2 dernières heures. Si un hôte est défaillant (ou qu'un commutateur intermédaire ou encore qu'un router soit défaillant) sans fermer la connexion TCP correctement, on le détecterait au bout de 2 heures (et quelques minutes). C'est biensûr, bien mieux que de ne jamais fermer la connexion (si KEEP_ALIVE est fermé - off ), mais n'est pas vraiment très utile. Donc, la première solution serait de diminuer la valeur du timeout de KEEP_ALIVE. Cela pourra uniquement être effectué pour le noyau dans son entier pour la plupart des systèmes d'exploitation, donc si le timeout est rendu à 15 minutes, cela affectera toutes les connexions TCP."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:579
@@ -1405,7 +1480,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 "Le deuxième solution consiste à combiner FD_SOCK et FD. Le timeout de FD pourrait être configuré de façon à être bien plus bas que celui du TCP, et cette configuration pourrait avoir lieu individuellement et par un processus à la fois. FD_SOCK ira déjà générer un message suspect si la connexion était fermée d'une façon anormale. Cependant, dans le cas d'un commutateur ou d'un hôte défaillant, FD veillera à ce que la connexion soit finalement fermée et que le message suspect soit généré. Exemple :"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:584
@@ -1416,6 +1491,10 @@
 "<FD timeout=\"10000\" max_tries=\"5\" shun=\"true\" \n"
 "down_thread=\"false\" up_thread=\"false\" /> ]]>"
 msgstr ""
+"<![CDATA[\n"
+"<FD_SOCK down_thread=\"false\" up_thread=\"false\"/>\n"
+"<FD timeout=\"10000\" max_tries=\"5\" shun=\"true\" \n"
+"down_thread=\"false\" up_thread=\"false\" /> ]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:586
@@ -1428,7 +1507,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 "Il suspecte un membre quand la connexion à un voisin a été fermée de façon anormale (c'est à dire plantage de processus, car les systèmes d'exploitation ferment toutes les connexions). Cependant, si un hôte ou un commutateur est défaillant, alors toutes les connexions seront suspendues, donc, en deuxième ligne de défense, FD suspectera le voisin après 50 secondes. Notes qu'avec cet exemple, si votre système s'interrompt au milieu d'un arrêt de contrôle dans le débogueur, le noeud que vos déboguez sera suspecté au bout de 50 secondes."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:589
@@ -1437,13 +1516,13 @@
 "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 "Une combinaison de FD et de FD_SOCK offre une couche solide de détection en cas de défaillance, et pour cette raison, une telle technique est utilisée à travers les configurations JGroups incluses dans le serveur JBoss Application."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:598
 #, no-c-format
 msgid "Reliable Delivery Protocols"
-msgstr ""
+msgstr "Delivery Protocols (protocoles de livraison) fiables"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:599
@@ -1455,13 +1534,13 @@
 "delivery acknowledgments (ACK and NAK). In the ACK mode, the sender resends "
 "the message until the acknowledgment is received from the receiver. In the "
 "NAK mode, the receiver requests retransmission when it discovers a gap."
-msgstr ""
+msgstr "L'assurance de protocoles de livraison fiables dans la pile JGroups, garantit que les poches de données sont livrées dans le bon ordre (FIFO) vers le noeud de destination. La base de livraison de messages fiables est l'accusé de réception (ACK ou NAK). En mode ACK, l'émetteur renvoie le message jusqu'à ce que l'accusé de réception soir reçu par le récepteur. En mode NAK, le récepteur demande la retransmission quand il découvre qu'il y a un manquement."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:606
 #, no-c-format
 msgid "UNICAST"
-msgstr ""
+msgstr "UNICAST"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:607
@@ -1472,7 +1551,7 @@
 "stack is configured with TCP transport protocol, UNICAST is not necessary "
 "because TCP itself guarantees FIFO delivery of unicast messages. Here is an "
 "example configuration for the <literal>UNICAST</literal> protocol."
-msgstr ""
+msgstr "Le protocole UNICAST est utilisé pour les messages unicast. Il utilise ACK. C'est configuré en tant que sous-élément sous l'élément JGroups Config. Si la pile JGroups est configurée avec le protocole de transport TCP, UNICAST n'est pas nécessaire car TCP lui-même garantit la livraison FIFO des messages unicast. Voici un exemple de configuration du protocole <literal>UNICAST</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:610
@@ -1481,6 +1560,8 @@
 "&lt;UNICAST timeout=\"100,200,400,800\"\n"
 "down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;UNICAST timeout=\"100,200,400,800\"\n"
+"down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:612
@@ -1488,7 +1569,7 @@
 msgid ""
 "There is only one configurable attribute in the <literal>UNICAST</literal> "
 "element."
-msgstr ""
+msgstr "Il n'existe qu'un attribut configurable dans l'élément <literal>UNICAST</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:615
@@ -1499,13 +1580,13 @@
 "\", the sender resends the message if it hasn't received an ACK after 100 ms "
 "the first time, and the second time it waits for 200 ms before resending, "
 "and so on."
-msgstr ""
+msgstr "<emphasis role=\"bold\">timeout</emphasis> détermine le timeout de retransmission (en millesecondes). Ainsi, si le timeout est de \"100,200,400,800\", l'émetteur renvoie le message s'il n'a pas reçu un ACK au bout de 100 ms la première fois, et la deuxième fois, il attend 200 ms avant de renvoyer, etc..."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:625
 #, no-c-format
 msgid "NAKACK"
-msgstr ""
+msgstr "NAKACK"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:626
@@ -1518,7 +1599,7 @@
 "retransmit the missing message. The NAKACK protocol is configured as the "
 "<literal>pbcast.NAKACK</literal> sub-element under the JGroups "
 "<literal>Config</literal> element. Here is an example configuration."
-msgstr ""
+msgstr "Le protocole NAKAK est utilisé pour les messages multicast. Il utilise NAK. Sous ce protocole, chaque message est balisé par un numéro de séquence. Le récepteur garde la trace des nombres de séquences et délivre les messages dans l'ordre. Quand on détecte un manquement dans les numéros de séquence, le récepteur demande à l'émetteur de retransmettre le message manquant. Le protocole NAKACK est configuré comme un sous-élément de <literal>pbcast.NAKACK</literal> sous l'élément de JGroups <literal>Config</literal> element. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:633
@@ -1530,6 +1611,11 @@
 "   discard_delivered_msgs=\"true\"\n"
 "   down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;pbcast.NAKACK max_xmit_size=\"60000\" use_mcast_xmit=\"false\" \n"
+"   \n"
+"   retransmit_timeout=\"300,600,1200,2400,4800\" gc_lag=\"0\"\n"
+"   discard_delivered_msgs=\"true\"\n"
+"   down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:636
@@ -1537,7 +1623,7 @@
 msgid ""
 "The configurable attributes in the <literal>pbcast.NAKACK</literal> element "
 "are as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément <literal>pbcast.NAKACK</literal> sont les suivants :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:639
@@ -1547,6 +1633,9 @@
 "retransmission timeout (in milliseconds). It is the same as the "
 "<literal>timeout</literal> attribute in the UNICAST protocol."
 msgstr ""
+"<emphasis role=\"bold\">retransmit_timeout</emphasis> précise le timeout de "
+"retransmission timeout (en milleseconds). C'est le même que celui de l'attribut"
+"<literal>timeout</literal> dans le protocole UNICAST."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:644
@@ -1556,7 +1645,7 @@
 "sender should send the retransmission to the entire cluster rather than just "
 "the node requesting it. This is useful when the sender drops the pocket -- "
 "so we do not need to retransmit for each node."
-msgstr ""
+msgstr "<emphasis role=\"bold\">use_mcast_xmit</emphasis> détermine  si l'émetteur doit envoyer la retransmission vers le cluster dans son entier plutôt que juste vers le noeud qui émet la demande. C'est utile quand l'émetteur abandonne la poche (pocket) -- et qu'on n'a pas besoin de retransmettre pour chaque noeud."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:650
@@ -1564,7 +1653,7 @@
 msgid ""
 "<emphasis role=\"bold\">max_xmit_size</emphasis> specifies maximum size for "
 "a bundled retransmission, if multiple packets are reported missing."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_xmit_size</emphasis> détermine la taille maximum pour une transmission groupée, si les paquets multiples sont reportés disparus."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:654
@@ -1574,7 +1663,7 @@
 "to discard delivery messages on the receiver nodes. By default, we save all "
 "delivered messages. However, if we only ask the sender to resend their "
 "messages, we can enable this option and discard delivered messages."
-msgstr ""
+msgstr "<emphasis role=\"bold\">discard_delivered_msgs</emphasis> détermine si on doit ignorer les messages de livraison sur les noeuds des récepteurs. Par défaut, on sauvegarde tous les messages livrés. Cependant, si on demande aux 'émetteurs de renvoyer leurs message, on peut activer cette option et ignorer les messages livrés.s"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:661
@@ -1582,7 +1671,7 @@
 msgid ""
 "<emphasis role=\"bold\">gc_lag specifies</emphasis> the number of messages "
 "garbage collection lags behind."
-msgstr ""
+msgstr "<emphasis role=\"bold\">gc_lag specifies</emphasis> détermine le nombre de messages en arrière dans l'espace de récupération de mémoire."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:672
@@ -1596,13 +1685,13 @@
 msgid ""
 "In addition to the protocol stacks, you can also configure JGroups network "
 "services in the <literal>Config</literal> element."
-msgstr ""
+msgstr "En plus des piles de protocole, vous pouvez également configurer les service de réseau JGroups dans l'élément <literal>Config</literal>."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:677
 #, no-c-format
 msgid "Group Membership"
-msgstr ""
+msgstr "Adhésion à un groupe"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:678
@@ -1615,7 +1704,7 @@
 "are notified if the group membership changes. The group membership service "
 "is configured in the <literal>pbcast.GMS</literal> sub-element under the "
 "JGroups <literal>Config</literal> element. Here is an example configuration."
-msgstr ""
+msgstr "Le service d'adhésion de groupe de la pile JGroups, maintient une liste des noeuds actifs. Il gère les requêtes de demande d'adhésion ou de sortie du cluster. Il s'occupe également des messages SUSPECT envoyés par les protocoles de détection de défaillance. Tous les noeuds du cluster, les équilibreurs des charges, et les intercepteurs côté-client, sont tenus au courant des changements d'adhésion au niveau groupe. Le service d'adhésion de groupes est configuré dans le sous-élément <literal>pbcast.GMS</literal> sous l'élément <literal>Config</literal>. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:684
@@ -1628,6 +1717,12 @@
 "    shun=\"true\"\n"
 "    view_bundling=\"true\"/&gt;"
 msgstr ""
+"&lt;pbcast.GMS print_local_addr=\"true\"\n"
+"    join_timeout=\"3000\"\n"
+"    down_thread=\"false\" up_thread=\"false\"\n"
+"    join_retry_timeout=\"2000\"\n"
+"    shun=\"true\"\n"
+"    view_bundling=\"true\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:688
@@ -1635,7 +1730,7 @@
 msgid ""
 "The configurable attributes in the <literal>pbcast.GMS</literal> element are "
 "as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément <literal>pbcast.GMS</literal> sont les suivants :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:691
@@ -1644,7 +1739,7 @@
 "<emphasis role=\"bold\">join_timeout</emphasis> specifies the maximum number "
 "of milliseconds to wait for a new node JOIN request to succeed. Retry "
 "afterwards."
-msgstr ""
+msgstr "<emphasis role=\"bold\">join_timeout</emphasis> détermine le nombre maximum de millesondes qu'il faut attendre pour qu'un nouvelle requête de joindre, JOIN, aboutisse. Essayer à nouveau ensuite."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:695
@@ -1652,7 +1747,7 @@
 msgid ""
 "<emphasis role=\"bold\">join_retry_timeout</emphasis> specifies the maximum "
 "number of milliseconds to wait after a failed JOIN to re-submit it."
-msgstr ""
+msgstr "<emphasis role=\"bold\">join_retry_timeout</emphasis> détermine le nombre maximum de millesecondes qu'il faut attendre après qu'une requête JOIN ait échoué avant de la soumettre à nouveau."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:699
@@ -1668,7 +1763,7 @@
 msgid ""
 "<emphasis role=\"bold\">shun</emphasis> specifies whether a node should shun "
 "itself if it receives a cluster view that it is not a member node."
-msgstr ""
+msgstr "<emphasis role=\"bold\">shun</emphasis> détermine si un noeud doit s'exclure de lui-même s'il reçoit une vue de cluster lui indiquant qu'il n'est pas un noeud membre."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:707
@@ -1676,7 +1771,7 @@
 msgid ""
 "<emphasis role=\"bold\">disable_initial_coord</emphasis> specifies whether "
 "to prevent this node as the cluster coordinator."
-msgstr ""
+msgstr "<emphasis role=\"bold\">disable_initial_coord</emphasis> détermine si ce noeud doit éviter de devenir le coordinateur du cluster."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:711
@@ -1687,12 +1782,14 @@
 "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> détermine si les requêtes multiples "
+"JOIN ou LEAVE qui arrivent au moment, sont groupées et gérées ensemble et au même moment, en émettant uniquement 1 nouvelle vue / ensemble. Cela est plus efficace que de gérer chaque requête séparemment."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:720
 #, no-c-format
 msgid "Flow Control"
-msgstr ""
+msgstr "Contrôle des flux"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:721
@@ -1711,7 +1808,7 @@
 "control service is configured in the <literal>FC</literal> sub-element under "
 "the JGroups <literal>Config</literal> element. Here is an example "
 "configuration."
-msgstr ""
+msgstr "Le service de contrôle des flux essaie d'adapter le taux d'émission des données et des données collectées entre les noeuds. Si un noeud d'émission est trop rapide, il risque de submerger le noeud récepteur et résulter en paquets largués ayant besoin d'être retransmis. Dans JGroups, le contrôle de flux est implémenté par un système basé-crédit. Les noeuds récepteurs et émetteurs ont le même nombre de crédits (octets) pour commencer. L'émetteur soustrait ses crédits par le nombre d'octets présents dans le message qu'il reçoit. Quand le nombre de crédits diminue au delà d'un certain seuil, le récepteur renvoie quelques crédits à l'émetteur. Si les crédits de l'émetteur sont totalement utilisés, l'émetteur est bloqué jusqu'à ce qu'il reçoive des crédits de la part de l'émetteur. Le service de contrôle de flux est configuré dans le sous-élément <literal>FC</literal> sous l'élément <literal>Config</literal>. Voici un exemple de!
  configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:732
@@ -1721,6 +1818,9 @@
 "down_thread=\"false\" up_thread=\"false\" \n"
 "    min_threshold=\"0.10\"/&gt;"
 msgstr ""
+"&lt;FC max_credits=\"1000000\"\n"
+"down_thread=\"false\" up_thread=\"false\" \n"
+"    min_threshold=\"0.10\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:735
@@ -1739,7 +1839,7 @@
 msgid ""
 "<emphasis role=\"bold\">max_credits</emphasis> specifies the maximum number "
 "of credits (in bytes). This value should be smaller than the JVM heap size."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_credits</emphasis> précise le nombre maximum de crédits (en octets). Cette valeur devrait être inférieure à la taille du tas JVM."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:742
@@ -1747,7 +1847,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_credits</emphasis> specifies the threshold "
 "credit on the sender, below which the receiver should send in more credits."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_credits</emphasis> détermine de seuil de crédit de l'émetteur, en dessous duquel le récepteur devrait envoyer plus de crédits."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:746
@@ -1755,7 +1855,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_threshold</emphasis> specifies percentage value "
 "of the threshold. It overrides the <literal>min_credits</literal> attribute."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_threshold</emphasis> détermine la valeur du pourcentage du seuil de tolérance. Il prend précédent sur l'attribut <literal>min_credits</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:750
@@ -1766,7 +1866,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> détermine le temps (en ms) maximum pendant lequel un émetteur peut bloquer. Si un émetteur bloque, et qu'aucun crédit n'a été reçu après 5 secondes, alors il envoie une demande de crédit explicite vers les récepteurs sont les crédits sont actuellement en dessous de 0, jusqu'à ce qu'il reçoive des crédits de la par de tous les membres dont les crédits sont en dessous de 0."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:755
@@ -1789,13 +1889,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 "Les applications qui utilisent les appels RPC de groupe synchronisés, n'ont pas foncièrement besoin du protocole FC dans leur pile de protocole JGroups car la communication synchrône, où le thread qui fait l'appel bloque en attendant des réponses de la part de tous les membres du groupe, ralentit déjà le taux moyen des appels. Même si TCP fournit un contrôle de flux en soi, on a toujours besoins de FC pour les piles JGroups basées TCP en raison de la communication de groupe, pour laquelle on doit essentiellement envoyer des messages de groupe à la vitesse la plus élevée tolérable par le récepteur le plus lent. Le contrôle de flux TCP ne prend en considération que les communications des noeuds individuels et n'a aucune notion de qui est le plus lent dans le groupe, et c'est la raison pour laquelle on a besoin de 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 "Pourquoi a-t-on besoin de FC au dessus de TCP ? TCP possède son propre système de contrôle de flux !"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:763
@@ -1811,7 +1911,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 "La raison est la communication de groupes, pour laquelle on doit essentiellement envoyer des messages de groupes à la vitesse la plus élevée possible que le récepteur le plus lent puisse soutenir. Imaginons que nous ayons un cluster {A,B,C,D}.D est lent (il est peut-être surchargé), le reste est rapide. Quand A envoie un message de groupe, il établit les connexions TCP A-A (conceptuellement), A-B, A-C et A-D (si elles n'existent pas encore). Donc, imaginons que A envoie 100 millions de messages vers le cluster. Comme le contrôle de flux de TCP ne s'applique qu'à A-B, A-C et A-D, mais pas à A-{B,C,D}, où {B,C,D} est le groupe, il est possible que A, B et C reçoivent 100M, mais que D ne reçoive qu'1M de messages. (A propos : c'est aussi la raison pour laquelle on a besoin de NAKACK, malgré que TCP fasse sa propre retransmission)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:767
@@ -1824,7 +1924,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 "Maintenant JGroups doit tamponner tous les messages en mémoire au cas où l'émetteur d'origine S ne meurt et qu'un noeud n'exige la retransmission d'un message de la part de S. Comme tous les membres tamponnent les messages qu'ils reçoivent, ils ont besoin de purger les messages stables (= les messages que tout le monde peut voir) de temps en temps. C'est effectué par l'intermédiaire du protocole STABLE, qui peut être configuré pour exécuter le protocole stability basé par tour/durée (par ex. toutes les 50s) ou basé par taille (à chaque fois que 400K de données ont été reçues)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:770
@@ -1836,7 +1936,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 "Dans le cas ci-dessus, le noeud qui est lent, D, va empêcher que le groupe ne purge des messages au dessus d'1M, de façon à ce que chaque membre puisse tamponner 99M de messages ! Cela mène, le plus souvent, à des exception OOM. Notez - que le protocole de fenêtre glissante de TCP entraînera le blocage d'écriture si la fenêtre est pleine - nous assumons dans le cas ci-dessus que c'est plus rapide pour A-B et A-C que pour A-D."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:773
@@ -1844,13 +1944,13 @@
 msgid ""
 "So, in summary, we need to send messages at a rate the slowest receiver (D) "
 "can handle."
-msgstr ""
+msgstr "Donc, pour résumer, nous avons besoin d'envoyer des messages à un taux que le récepteur le plus lent (D) puisse soutenir."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:779
 #, no-c-format
 msgid "So do I always need FC?"
-msgstr ""
+msgstr "Donc, est-ce que j'ai toujours besoin de FC ?"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:780
@@ -1860,7 +1960,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 "Cela dépend de la façon dont l'application utilise le canal JGroups. En se reportant à l'exemple ci-dessus, s'il y avait quelquechose dans l'application qui pourrait entraîner le ralentissement du taux d'émission de A parce que D ne peut pas suivre, alors on n'aurait pas besoin de FC."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:783
@@ -1911,7 +2011,7 @@
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:802
 #, no-c-format
 msgid "Fragmentation"
-msgstr ""
+msgstr "Fragmentation"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:803
@@ -1921,7 +2021,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 "Ce protocole fragmente des messages supérieurs à une certaine taille. Défragmente du côté du récepteur. Cela fonctionne à la fois pour les messages unicast et les messages multicast. Il est configuré dans le sous-élément FRAG2 sous l'élément JGroups Config. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:806
@@ -1931,12 +2031,15 @@
 "                <FRAG2 frag_size=\"60000\" down_thread=\"false\" up_thread="
 "\"false\"/>]]>"
 msgstr ""
+"<![CDATA[        \n"
+"                <FRAG2 frag_size=\"60000\" down_thread=\"false\" up_thread="
+"\"false\"/>]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:808
 #, no-c-format
 msgid "The configurable attributes in the FRAG2 element are as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément FRAG2 sont les suivants."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:813
@@ -1944,7 +2047,7 @@
 msgid ""
 "<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in "
 "bytes. Messages larger than that are fragmented."
-msgstr ""
+msgstr "<emphasis role=\"bold\">frag_size</emphasis> détermine la taille maximum de fragmentation en octets. Les plus grands messages seront fragmentés."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:817
@@ -1954,13 +2057,13 @@
 "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 "Le protocole TCP procure déjà une fragmentation, mais un protocole JGroups de fragmentation est toujours requis si FC est utilisé. La raison pour cela, c'est que si vous envoyez un message plus grand que FC.max_bytes, le protocole FC bloquerait. Donc, dans FRAG2, frag_size aura besoin d'être toujours inférieur à FC.max_bytes."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:826
 #, no-c-format
 msgid "State Transfer"
-msgstr ""
+msgstr "Transfert d'états"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:827
@@ -1971,19 +2074,19 @@
 "<literal>pbcast.STATE_TRANSFER</literal> sub-element under the JGroups "
 "<literal>Config</literal> element. It does not have any configurable "
 "attribute. Here is an example configuration."
-msgstr ""
+msgstr "Le service de transfert d'états transfère l'état à partir d'un noeud existant (c'est à dire, le coordinateur du cluster) sur un noeud nouvellement rejoint. Il est configuré dans le sous-élément <literal>pbcast.STATE_TRANSFER</literal> sous l'élément <literal>Config</literal>. Il n'a pas d'attribut configurable. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:831
 #, no-c-format
 msgid "&lt;pbcast.STATE_TRANSFER down_thread=\"false\" up_thread=\"false\"/&gt;"
-msgstr ""
+msgstr "&lt;pbcast.STATE_TRANSFER down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:835
 #, no-c-format
 msgid "Distributed Garbage Collection"
-msgstr ""
+msgstr "Service de nettoyage de la mémoire distribué"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:836
@@ -1997,7 +2100,7 @@
 "service is configured in the <literal>pbcast.STABLE</literal> sub-element "
 "under the JGroups <literal>Config</literal> element. Here is an example "
 "configuration."
-msgstr ""
+msgstr "Dans un cluster JGroups, tous les noeuds doivent stocker tous les messages reçus en vue de retransmission potentielle, en cas de défaillance. Cependant, si on stocke tous les messages indéfiniement, nous allons manquer d'espace mémoire. Donc, le service de nettoyage distribué de JGroups purge périodiquement les messages identifiés par les noeuds de la mémoire, pour chaque noeud. Le service de nettoyage distribué est configuré dans le sous-élément <literal>pbcast.STABLE</literal> sous l'élément JGroups <literal>Config</literal>. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:840
@@ -2008,6 +2111,10 @@
 "    down_thread=\"false\" up_thread=\"false\"\n"
 "       max_bytes=\"400000\"/&gt;"
 msgstr ""
+"&lt;pbcast.STABLE stability_delay=\"1000\"\n"
+"    desired_avg_gossip=\"5000\" \n"
+"    down_thread=\"false\" up_thread=\"false\"\n"
+"       max_bytes=\"400000\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:842
@@ -2015,7 +2122,7 @@
 msgid ""
 "The configurable attributes in the <literal>pbcast.STABLE</literal> element "
 "are as follows."
-msgstr ""
+msgstr "Les attributs configurables de l'élément <literal>pbcast.STABLE</literal> sont les suivants :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:845
@@ -2025,6 +2132,9 @@
 "(in milliseconds) of garbage collection runs. Value <literal>0</literal> "
 "disables this service."
 msgstr ""
+"<emphasis role=\"bold\">desired_avg_gossip</emphasis> détermine les intervalles"
+"(en millesecondes) entre les sessions de nettoyage. La valeur <literal>0</literal> "
+"désactive ce service."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:850
@@ -2033,7 +2143,7 @@
 "<emphasis role=\"bold\">max_bytes</emphasis> specifies the maximum number of "
 "bytes received before the cluster triggers a garbage collection run. Value "
 "<literal>0</literal> disables this service."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_bytes</emphasis> détermine le nombre maximum d'octets reçus avant qu'un cluster ne déclenche un nettoyage. La valeur <literal>0</literal> désactive ce service."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:855
@@ -2042,7 +2152,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> détermine le délai précédant l'envoi d'un msg STABILITY (ce qui donne une chance aux autres d'envoyer avant). Si c'est utilisé en conjonction avec max_bytes, cet attribut devrait être paramétré avec un nombre inférieur."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:859
@@ -2050,13 +2160,13 @@
 msgid ""
 "Set the <literal>max_bytes</literal> attribute when you have a high traffic "
 "cluster."
-msgstr ""
+msgstr "Paramétrez l'attribut <literal>max_bytes</literal> quand vous avez un haut volume de trafic dans le cluster."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:864
 #, no-c-format
 msgid "Merging"
-msgstr ""
+msgstr "Fusion"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:865
@@ -2068,7 +2178,7 @@
 "cluster back again. The flow control service is configured in the "
 "<literal>MERGE2</literal> sub-element under the JGroups <literal>Config</"
 "literal> element. Here is an example configuration."
-msgstr ""
+msgstr "Quand on a une erreur de réseau, le cluster peut être partitionné en plusieurs partitions séparées. JGroups possède une service MERGE (FUSION) qui permet aux coordinateurs des partitions de communiquer les uns avec les autres pour finalement reformer un cluster unique. Le service de contrôle de flux est configuré dans le sous-élément <literal>MERGE2</literal> sous l'élément JGroups <literal>Config</literal>. Voici un exemple de configuration."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:869
@@ -2078,6 +2188,9 @@
 "    min_interval=\"2000\"\n"
 "    down_thread=\"false\" up_thread=\"false\"/&gt;"
 msgstr ""
+"&lt;MERGE2 max_interval=\"10000\"\n"
+"    min_interval=\"2000\"\n"
+"    down_thread=\"false\" up_thread=\"false\"/&gt;"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:875
@@ -2085,7 +2198,7 @@
 msgid ""
 "<emphasis role=\"bold\">max_interval</emphasis> specifies the maximum number "
 "of milliseconds to send out a MERGE message."
-msgstr ""
+msgstr "<emphasis role=\"bold\">max_interval</emphasis> détermine le nombre maximum de millesecondes avant d'envoyer un message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:879
@@ -2093,7 +2206,7 @@
 msgid ""
 "<emphasis role=\"bold\">min_interval</emphasis> specifies the minimum number "
 "of milliseconds to send out a MERGE message."
-msgstr ""
+msgstr "<emphasis role=\"bold\">min_interval</emphasis> détermine le nombre minimum de millesecondes pour envoyer un message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:883
@@ -2102,6 +2215,8 @@
 "JGroups chooses a random value between <literal>min_interval</literal> and "
 "<literal>max_interval</literal> to send out the MERGE message."
 msgstr ""
+"JGroups choisit une valeur au hasard entre <literal>min_interval</literal> et "
+"<literal>max_interval</literal> pour envoyer le message MERGE (FUSION)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:886
@@ -2115,13 +2230,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 "Les états du cluster ne sont pas fusionnés dans un merger. Cela doit être fait par l'application. Si <literal>MERGE2</literal> est utilisé en conjonction avec TCPPING, l'attribut <literal>initial_hosts</literal> devra contenir tous les noeuds qui pourraient être potentiellement fusionnés à nouveau, pour que le processus de fusionnement fonctionne correctement. Sinon, le processus de fusionnement ne s'appliquerait pas tous les noeuds, même si shunning (exclusion) était désactivé. Sinon, utiliser MPING, qui est normalement utilisé avec TCP pour offrir des capacités discovery aux membre multicast, à la place de TCPPING pour éviter d'avoir à spécifier tous les noeuds."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:892
 #, no-c-format
 msgid "Binding JGroups Channels to a particular interface"
-msgstr ""
+msgstr "Lier les canaux JGroups à une interface particulière"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:893
@@ -2130,7 +2245,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 "Dans la section Protocoles de Transport ci-dessus, nous abordons brièvement comment l'interface par laquelle JGroups va lier les sockets, est configurée. Penchons-nous davantage sur ce sujet :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:896
@@ -2143,7 +2258,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 "Tout d'abord, il est important de comprendre que la valeur déterminée dans n'importe quel élément bind_addr d'un fichier de configuration XML, sera ignoré par JGroups s'il établit que la propriété de système jgroups.bind_addr (ou un ancien nom s'appliquant à la même chose, <literal>bind.address</literal>) a été déterminée. La propriété de système éclipse XML. Si JBoss AS commence par le commutateur -b (ou bien --host), AS configurera <literal>jgroups.bind_addr</literal> avec une valeur spécifique."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:899
@@ -2161,19 +2276,19 @@
 msgid ""
 "So, what are <emphasis>best practices</emphasis> for managing how JGroups "
 "binds to interfaces?"
-msgstr ""
+msgstr "Donc, quelles sont les <emphasis>meilleures pratiques</emphasis> pour gérer comment JGroups fait la liaison avec 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 "Pour relier JGroups à la même interface que les autres services, utilisez simplement -b :"
 
 #. Tag: screen
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:909
 #, no-c-format
 msgid "./run.sh -b 192.168.1.100 -c all"
-msgstr ""
+msgstr "./run.sh -b 192.168.1.100 -c all"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:913
@@ -2185,6 +2300,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 ""
+"Relier les services (par ex., JBoss Web) à une interface, mais utiliser une interface différente pour JGroups : <screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>. Paramétrer une propriété système prévaut sur la valeur -b. C'est un usage courant qui consiste à mettre le trafic client sur un réseau, et le trafic intra-cluster sur un autre."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:921
@@ -2196,7 +2313,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 "Relier les services (par ex. JBoss Web) à toutes les interfaces. Cela pourrait être fait de cette façon : <screen>./run.sh -b 0.0.0.0 -c all</screen>. Cependant, cela n'amènera pas JGroups à se relier à toutes les interfaces ! A la place, JGroups se reliera à l'interface par défaut de la machine. Voir la section Protocoles de Transport pour la façon d'indiquer à JGroups comment recevoir en émettre sur toutes les interfaces, si c'est vraiment ce que vous souhaitez."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:929
@@ -2207,18 +2324,20 @@
 "bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
 "system property overrides the -b value."
 msgstr ""
+"Relier les services (par ex. JBoss Web) à toutes les interfaces, mais préciser l'interface JGroups : <screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen>. Ici aussi, configurer spécifiquement la propriété du système prévaut sur la valeur -b."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:937
 #, no-c-format
 msgid "Using different interfaces for different channels:"
-msgstr ""
+msgstr "Utiliser des interfaces différentes pour des canaux différents :"
 
 #. Tag: screen
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:939
 #, no-c-format
 msgid "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
-msgstr ""
+msgstr "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:944
@@ -2228,13 +2347,13 @@
 "literal> system property, and instead use whatever is specfied in XML. You "
 "would need to edit the various XML configuration files to set the "
 "<literal>bind_addr</literal> to the desired interfaces."
-msgstr ""
+msgstr "Cette configuration indique à JGroups d'ignorer la propriété de système <literal>jgroups.bind_addr</, et utiliser à la place ce qui est spécifié dans XML. Vous devrez éditer les divers fichiers de configuration pour paramétrer <literal>bind_addr</literal> aux interfaces désirées."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:949
 #, no-c-format
 msgid "Isolating JGroups Channels"
-msgstr ""
+msgstr "Isoler les canaux JGroups"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:950
@@ -2245,7 +2364,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 "Dans JBoss AS, il existe un certain nombre de services qui créent indépendemment des canaux JGroups -- 3 services JBoss Cache différents (utilisés pour la replication de session Http, la réplication EJB3 SFSB, et la réplication d'entité EJB3), accompagnés du service de clustering d'intérêt général, nommé HAPartition qui est à la base de la plupart des autres services JBossHA."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:953
@@ -2256,7 +2375,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 "Il est critique que ces canaux puissent uniquement communiquer avec leurs homologues spécifiques, et non pas à travers les canaux utilisés par d'autres services, ni avec des canaux du même service disponible à des machines qui ne devraient pas faire partie du groupe. Le fait que les noeuds puissent mal communiquer entre eux, est l'un des problèmes les plus courants auxquels les utilisateurs puissent rencontrer avec le clustering JBoss."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:956
@@ -2266,7 +2385,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 "Le nom de groupe, l'adresse multicast, et le port multicast définissent avec qui un canal JGroups pourra communiquer. Donc, pour isoler les canaux JGroups, il s'agit de veiller à ce que différents canaux utilisent des valeurs différentes pour le nom de groupe, l'adresse multicast et le port multicast."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:959
@@ -2275,7 +2394,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 "Pour isoler les canaux JGroups sur différents services sur le même groupe d'instances AS, vous DEVEZ changer le nom du groupe et le port multicast. En d'autres mots, chaque canal doit posséder son propre ensemble de valeurs."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:962
@@ -2286,7 +2405,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 "Ainsi, imaginons que nous ayons un cluster de production de 3 machines, possédant chacune une HAPartition déployée aux côté d'un JBoss Cache utilisé pour le clustering de sessions web. Les canaux HAPartition ne devraient pas communiquer avec les canaux JBoss Cache. Ils devraient utiliser un nom de groupe et un port multicast différents. Ils peuvent utiliser la même adresse multicast, mais ils ne sont pas obligés."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:965
@@ -2295,7 +2414,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 "Pour isoler les canaux JGroups d'autre instances du service sur le réseau, pour un même service, vous DEVEZ changer TOUTES les trois valeurs. Chaque canal doit avoir son propre nom de groupe, son adresse multicast et son port multicast."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:968
@@ -2306,13 +2425,13 @@
 "of 3 machines, which also has an HAPartition deployed. The HAPartition group "
 "name, multicast address, and multicast port for the production machines must "
 "be different from those used on the QA machines."
-msgstr ""
+msgstr "Ainsi, imaginons que nous ayons un cluster de production de 3 machines, possédant chacune une HAPartition déployée. Sur ce même réseau, il y a aussi un cluster QA de 3 machines, avec HAPartition de déployé également. Le nom de groupe, l'adresse multicast, et le port multicast HAPartition des machines de production doivent être différents de ceux qui sont utilisés sur les machines QA."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:974
 #, no-c-format
 msgid "Changing the Group Name"
-msgstr ""
+msgstr "Changer le nom de groupe"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:975
@@ -2324,7 +2443,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 "Le nom de groupe des canaux JGroups est configuré par le service qui démarre le canal. Malheureusement, des services différents utilisent des noms d'attribut différents pour le configurer. Pour la partition HAPartition et les services liés, configurés dans le fichier depoy/cluster-service.xml, c'est configuré par un attribut PartitionName. Pour les services Jboss Cache, le nom de l'attribut est ClusterName."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:978
@@ -2338,6 +2457,8 @@
 "configuration of the group name in all the standard clustering configuration "
 "files. For example,"
 msgstr ""
+"En commençant avec JBoss AS 4.0.4, pour HAPartition et pour tous les services standards JBoss Cache, nous facilitons la création des noms de groupes uniques, en utilisant simplement le commutateur -g (ou -partition) au moment du démarrage de JBoss :<screen>./"
+"run.sh -g QAPartition -b 192.168.1.100 -c all</screen>. Ce commutateur définit la propriété de système jboss.partition.name, qui est utilisée en tant que composant de la configuration du nom de groupe dans tous les fichiers de configuration de clustering standards. Ainsi,"
 
 #. Tag: screen
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:982
@@ -2346,12 +2467,14 @@
 "<![CDATA[<attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:"
 "Cluster}</attribute>]]>"
 msgstr ""
+"<![CDATA[<attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:"
+"Cluster}</attribute>]]>"
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:988
 #, no-c-format
 msgid "Changing the multicast address and port"
-msgstr ""
+msgstr "Changer l'adresse multicast et le port"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:989
@@ -2364,6 +2487,9 @@
 "udpGroup system property, which you can see referenced in all of the "
 "standard protocol stack configs in JBoss AS:"
 msgstr ""
+"La ligne de commande -u (a.k.a. --udp) peut être utilisée pour contrôler l'adresse multicast utilisée par les canaux JGroups qui sont ouverts par tous les services AS standard. <screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b "
+"192.168.1.100 -c all]]></screen> Ce commutateur détermine la propriété de système jboss.partition."
+"udpGroup, que vous pouvez voir référencée dans toutes les configurations de piles de protocoles standards dans JBoss AS."
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:995
@@ -2373,6 +2499,9 @@
 "<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\"\n"
 " ....]]>"
 msgstr ""
+"<![CDATA[<Config>\n"
+"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\"\n"
+" ....]]>"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:996
@@ -2384,7 +2513,7 @@
 "are no command line switches to set these, but the standard configuration "
 "files do use system properties to set them. So, they can be configured from "
 "the command line by using -D. For example,"
-msgstr ""
+msgstr "Malheureusement, configurer les ports multicast n'est pas une tâche simple. Comme nous l'avons décrit plus haut, il existe par défaut quatre canaux JGroups séparés dans la configuraiton JBoss AS all, et chaque canal devrait être associé à un port unique. Il n'y a pas de commutateurs de lignes de commande pour les installer, mais les fichiers de configuration standard utilisent des propriétés de système pour les configurer. Ainsi, ils peuvent être configurés à partir de la ligne de commande en utilisant -D. Par exemple,"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:999
@@ -2395,12 +2524,16 @@
 "mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 "
 "-c all"
 msgstr ""
+"/run.sh -u 230.1.2.3 -g QAPartition -Djboss.hapartition.mcast_port=12345 -"
+"Djboss.webpartition.mcast_port=23456 -Djboss.ejb3entitypartition."
+"mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 "
+"-c all"
 
 #. Tag: emphasis
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1001
 #, no-c-format
 msgid "Why isn't it sufficient to change the group name?"
-msgstr ""
+msgstr "Pourquoi n'est-il pas suffisant de changer le nom de groupe ?"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1002
@@ -2410,13 +2543,13 @@
 "port, the lower level JGroups protocols in each channel will see, process "
 "and eventually discard messages intended for the other group. This will at a "
 "minimum hurt performance and can lead to anomalous behavior."
-msgstr ""
+msgstr "Si des canaux associés à des noms de groupe différents partagent le mêm port et la même adresse multicast, les protocoles JGroups de bas niveau, pour chaque canal, trouvera, traitera et finalement se débarrassera de messages destinés à l'autre groupe. Cela aura pour conséquence de diminuer la performance, au minimum, voire entraîner dun comportement anormal."
 
 #. Tag: emphasis
 #: 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 "Pourquoi devrais-je changer le port multicast si je change l'adresse ?"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1007
@@ -2427,19 +2560,19 @@
 "multicast port are delivered to all listeners on that port, regardless of "
 "the multicast address they are listening on. So the recommendation is to "
 "change both the address and the port."
-msgstr ""
+msgstr "Changer l'adresse uniquement devrait suffire, mais il existe un problème sur plusieurs systèmes d'exploitation, quand des paquets adressés à un port particulier multicast, sont livrés à tous les listeners de ce port, quelque soit l'adresse multicast sur laquelle ils sont branchés. Donc, la recommandation est de changer à la fois l'adresse et le port."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1013
 #, no-c-format
 msgid "JGroups Troubleshooting"
-msgstr ""
+msgstr "Résolutions de pannes dans JGroups"
 
 #. Tag: emphasis
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1014
 #, no-c-format
 msgid "Nodes do not form a cluster"
-msgstr ""
+msgstr "Les noeuds ne forment pas un cluster"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1016
@@ -2450,6 +2583,9 @@
 "McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> "
 "directory and start McastReceiverTest, for example:"
 msgstr ""
+"Veillez à ce que votre machine soit configurée correctement pour IP multicast. Il existe 2 programmes test qui peuvent être utilisés pour le détecter :  McastReceiverTest et "
+"McastSenderTest. Aller dans le répertoire<literal>$JBOSS_HOME/server/all/lib</literal> "
+"et démarrez McastReceiverTest, par exemple :"
 
 #. Tag: screen
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1018
@@ -2458,12 +2594,14 @@
 "java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr "
 "224.10.10.10 -port 5555"
 msgstr ""
+"java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr "
+"224.10.10.10 -port 5555"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1021
 #, no-c-format
 msgid "Then in another window start <literal>McastSenderTest</literal>:"
-msgstr ""
+msgstr "Puis, dans une autre fenêtre, démarrez <literal>McastSenderTest</literal> :"
 
 #. Tag: screen
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1023
@@ -2472,6 +2610,8 @@
 "java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr "
 "224.10.10.10 -port 5555"
 msgstr ""
+"java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr "
+"224.10.10.10 -port 5555"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1026
@@ -2481,7 +2621,7 @@
 "<literal>-bind_addr 192.168.0.2</literal>, where 192.168.0.2 is the IP "
 "address of the NIC to which you want to bind. Use this parameter in both the "
 "sender and the receiver."
-msgstr ""
+msgstr "Si vous souhaitez vous relier à une carte d'interface de réseau (NIC) précise, utilisez <literal>-bind_addr 192.168.0.2</literal>, où 192.168.0.2 est l'adresse IP du NIC auquel vous souhaitez vous relier. Utiliser ce paramètre à la fois pour l'émetteur et le récepteur."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1029
@@ -2496,13 +2636,13 @@
 "Once you know multicast is working properly on each machine in your cluster, "
 "you can repeat the above test to test the network, putting the sender on one "
 "machine and the receiver on another."
-msgstr ""
+msgstr "Vous devriez pouvoir saisir des informations dans la fenêtre <literal>McastSenderTest</literal> et observer la sortie dans la fenêtre <literal>McastReceiverTest</literal>. Sinon, essayez d'utiliser -ttl 32 pour l'émetteur. Si cela échoue également, consultez l'administrateur de systèmes pour vous aider à installer IP multicast correctement, et demandez à l'administrateur de veiller à ce que multicast fonctionne sur l'interface que vous avez choisie, ou bien, si les machines ont des interfaces multiples, exigez de connaître l'interface qui convient. Une fois que multicast fonctionne correctement sur chaque machine du cluster, vous pourrez répéter le test ci-dessus pour tester le réseau, en mettant l'émetteur sur une machine et le récepteur sur une autre."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1036
 #, no-c-format
 msgid "Causes of missing heartbeats in FD"
-msgstr ""
+msgstr "Causes des heartbeats manquants dans FD"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1037
@@ -2512,7 +2652,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 "Parfois, un membre est rendu suspect par FD car un ACK heartbeat n'a pas été reçu depuis un moment T - défini par timeout (le délai d'inactivité) et max_tries (un nombre maximum de tentatives). Cela peut avoir à la base plusieurs raisons, par ex. dans un cluster donné A'B'C'D; C peut être rendu suspect si ( notez bien que A ping B, B ping C, C ping D et D ping A) :"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1043
@@ -2520,19 +2660,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 ou C exécutent à 100% du CPU pour plus de T secondes. Donc, même si C envoie un ack heartbeat à B, B ne sera peut-être pas en mesure de le traiter car il est à 100%"
 
 #. 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 et C font le nettoyage, comme ci-dessus."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1053
 #, no-c-format
 msgid "A combination of the 2 cases above"
-msgstr ""
+msgstr "Une combinaison des 2 cas décrits ci-dessus"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1058
@@ -2541,7 +2681,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 "Le réseau perd des paquets. Cela arrive normalement quand il y a trop de trafic sur le réseau, et le commutateur commence à larguer des paquets (normalement broadcasts tout d'abord, puis IP multicasts, et TCP packets pour terminer)."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:1063
@@ -2551,5 +2691,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 ou C sont entrain de traiter un callback. Disons que C a reçu un appel méthode distant sur son canal et qu'il prenne T+1 pour le traiter. Pendant ce temps, C ne traitera pas d'autres messages, y compris les heartbeats, et donc B ne recevra pas d'ack heartbeat et suspectera C."
 




More information about the jboss-cvs-commits mailing list