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

[jboss-cvs-commits at lists.jboss.org]

Author: croe at redhat.com
Date: 2009-03-31 02:17:26 -0400 (Tue, 31 Mar 2009)
New Revision: 86512

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/Naming.po
Log:
PR in progress - Clustering Guide JBoss Cache JGroups in SCG inclusive

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-03-31 06:03:42 UTC (rev 86511)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po	2009-03-31 06:17:26 UTC (rev 86512)
@@ -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-03-27 09:45+1000\n"
+"PO-Revision-Date: 2009-03-31 16:14+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -47,7 +47,7 @@
 "Clustering is crucial for highly available enterprise applications, as it is "
 "the clustering infrastructure that supports the redundancy needed for high "
 "availability."
-msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèlement (ou noeuds de clusters) tout en fournissant une seule vue aux clients de l'application. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs serveurs sont défaillants, l'application est toujours accessible via les noeuds du cluster qui ont pu survivre. Clustering est crucial aux applications d'entreprises modulables, car vous pouvez toujours améliorer la performance en ajoutant simplement des noeuds supplémentaires dans le cluster. Clustering est crucial aux applications d'entreprises hautement disponibles, car c'est l'infrastructure de clustering qui supporte la redondance qu'il faut, pour permettre un haut niveau de disponiblité des applications."
+msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèlement (ou noeuds de clusters) tout en fournissant une seule vue de l'application aux clients. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs serveurs sont défaillants, l'application est toujours accessible via les noeuds du cluster qui ont pu survivre. Clustering est crucial aux applications d'entreprises modulables, car vous pouvez toujours améliorer la performance en ajoutant simplement des noeuds supplémentaires dans le cluster. Clustering est crucial aux applications d'entreprises hautement disponibles, car c'est l'infrastructure de clustering qui supporte la redondance qu'il faut, pour permettre un haut niveau de disponibilité des applications."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:14
@@ -97,7 +97,7 @@
 "and name that matches the other cluster members. In summary, a JBoss cluster "
 "is a set of AS server instances each of which is running an identically "
 "configured and named JGroups Channel."
-msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres dans un but commun. Dans un cluster JBoss Application Server (également connu sous le nom de \"partition\"), un noeud est une instance JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication de groupes JGroups, avec un canal JGroup Channel qui fournit une fonctionnalité de base pour pouvoir tracer qui est dans le cluster et pour pouvoir échanger des messages entre les membres du cluster. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres de façon dynamique, et de former un groupe. C'est pourquoi simplement exécuter un \"run -c all\" sur deux instances AS du même réseau leur suffit pour former un cluster - chaque AS démarre un canal (ou plutôt, un certain nombre de canaux) avec la même configuration par défaut, de façon à ce qu'ils puissent se découvrir!
  dynamiquement les uns les autres et former un cluster. Les noeuds peuvent être dynamiquement ajoutés et retirés des clusters à tout moment, simplement en démarrant ou en arrêtant un canal grâce à une configuration et à un nom qui correspondent à ceux des autres membres d'un cluster. En bref, a cluster JBoss est un ensemble d'instances de serveurs AS exécutant un canal JGroups Channel configuré et nommé de manière identique."
+msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres dans un but commun. Dans un cluster JBoss Application Server (également connu sous le nom de \"partition\"), un noeud est une instance JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication de groupes JGroups, avec un canal JGroup Channel, qui fournit une fonctionnalité de base pour pouvoir tracer qui es trouve dans le cluster et pour pouvoir échanger des messages entre les membres du cluster. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres de façon dynamique, et de former un groupe. C'est pourquoi simplement exécuter un \"run -c all\" sur deux instances AS du même réseau leur suffit pour former un cluster - chaque AS démarre un canal (ou plutôt, un certain nombre de canaux) avec la même configuration par défaut, de façon à ce qu'ils puissent se dé!
 couvrir dynamiquement les uns les autres et former un cluster. Les noeuds peuvent être dynamiquement ajoutés et retirés des clusters à tout moment, simplement en démarrant ou en arrêtant un canal grâce à une configuration et à un nom qui correspondent à ceux des autres membres d'un cluster. En bref, a cluster JBoss est un ensemble d'instances de serveurs AS exécutant un canal JGroups Channel configuré et nommé de manière identique."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:29
@@ -431,7 +431,7 @@
 "clustering architecture is illustrated in <xref linkend=\"clustering-"
 "InterceptorArch.fig\"/>."
 msgstr ""
-"Les intercepteurs stub maintiennent une connaissance mise à jour du groupement. Par exemple, ils connaissent les adresses IP de tous les noeuds de serveurs disponibles, l'algorithme de distribution des charges à travers les noeuds (voir la section suivante), et comment faire échouer une demande si le noeud cible n'est pas disponible. Dans le cadre de la gestion de chaque demande de service, quand la topologie du cluster change, le noeud du serveur met à jour l'intercepteur du stub à la lumière des derniers changements opérés dans le cluster. Ainsi, si un noeud sort du cluster, chacun des intercepteurs stub du client est mis à jour avec la nouvelle configuration la prochaine fois qu'il se connecte à un noeud actif au sein du cluster. Toutes les manipulations faites par le stub de service sont transparentes dans l'application du client. L'architecture de clustering de l'intercepteur côté-client, est illustrée dans <xref linkend=\"clustering-"
+"Les intercepteurs stub maintiennent une connaissance mise à jour du groupement. Par exemple, ils connaissent les adresses IP de tous les noeuds de serveurs disponibles, l'algorithme de distribution des charges à travers les noeuds (voir la section suivante), et comment faire échouer une demande si le noeud cible n'est pas disponible. Dans le cadre de la gestion de chaque demande de service, quand la topologie du cluster change, le noeud du serveur met à jour l'intercepteur du stub, à la lumière des derniers changements opérés dans le cluster. Ainsi, si un noeud sort du cluster, chacun des intercepteurs stub du client est mis à jour avec la nouvelle configuration la prochaine fois qu'il se connecte à un noeud actif au sein du cluster. Toutes les manipulations faites par le stub de service sont transparentes dans l'application du client. L'architecture de clustering de l'intercepteur côté-client, est illustrée dans <xref linkend=\"clustering-"
 "InterceptorArch.fig\"/>."
 
 #. Tag: title
@@ -476,7 +476,7 @@
 "architecture is illustrated in <xref linkend=\"clustering-BalancerArch.fig\"/"
 ">."
 msgstr ""
-"Les autres services JBoss, les services basés-HTTP en particulier, n'exigent pas du client de télédécharger quoi que ce soit. Le client (par ex., un navigateur Web) émet des requêtes et reçoit des réponses par câble directement en fonction de certains protocoles de communication ( comme le protocole HTTP). Dans ce cas, l'équilibreur des charges doit traiter toutes les demandes et les renvoyer vers les noeuds du serveur dans le cluster. Le client a juste besoin de savoir comment entrer en contact avec l'équilibreur des charges. Il ne possède aucune connaissance des instances JBoss AS en dehors de l'équilibreur des charges. L'équilibreur des charges fait logiquement partie du cluster, mais on y fait référence en tant qu'\"externe\" car il n'est pas exécuté dans le même processus que les instances JBoss As ou du client. Il peut être implémenté soit au niveau programme, soit au niveau du matériel. Il existe de nombreux distributeurs de matériel d'équil!
 ibrage de charges, comme le module mod_jk Apache qui constitue un excellent exemple. Un équilibreur de charges externe implémente ses propres mécanismes pour comprendre la configuration du cluster et fournit ses propres politiques associées aux cas de défaillance ou d'équilibrage des charges. L'architecture de mise en grappe d'équilibreur de charges externe est illustrée dans <xref linkend=\"clustering-BalancerArch.fig\"/"
+"Les autres services JBoss, les services basés-HTTP en particulier, n'exigent pas du client de télédécharger quoi que ce soit. Le client (par ex., un navigateur Web) émet des requêtes et reçoit des réponses par câble directement en fonction de certains protocoles de communication (comme le protocole HTTP). Dans ce cas, l'équilibreur des charges doit traiter toutes les demandes et les renvoyer vers les noeuds du serveur dans le cluster. Le client a juste besoin de savoir comment entrer en contact avec l'équilibreur des charges. Il ne possède aucune connaissance des instances JBoss AS en dehors de l'équilibreur des charges. L'équilibreur des charges fait logiquement partie du cluster, mais on y fait référence en tant qu'\"externe\" car il n'est pas exécuté dans le même processus que les instances JBoss As ou du client. Il peut être implémenté soit au niveau programme, soit au niveau du matériel. Il existe de nombreux distributeurs de matériel d'équili!
 brage de charges, comme le module mod_jk Apache qui constitue un excellent exemple. Un équilibreur de charges externe implémente ses propres mécanismes pour comprendre la configuration du cluster et fournit ses propres politiques associées aux cas de défaillance ou d'équilibrage des charges. L'architecture de mise en grappe d'équilibreur de charges externe est illustrée dans <xref linkend=\"clustering-BalancerArch.fig\"/"
 ">."
 
 #. Tag: title
@@ -629,7 +629,7 @@
 "cluster server nodes farm folder (triggers undeployment.) You should "
 "manually delete the application from the farm folder of any server node not "
 "currently connected to the cluster."
-msgstr "La façon la plus simple de déployer une application dans le cluster est d'utiliser le service 'farming'. C'est pour déployer à chaud le fichier des archives de l'application (comme le fichier EAR, WAR ou SAR) dans le répertoire <code>all/farm/</code> de n'importe quel membre du cluster et l'application sera automatiquement dupliquée à travers les noeuds du même cluster. Si le noeud rejoint le cluster plus tard, toutes les applications 'farming' déployées seront attirées vers le cluster et elles seront déployées localement au démarrage. Si vous supprimez l'application d'un des dossiers <literal>farm/</literal> de noeud de serveur du groupement en cours d'exécution, le déploiement de l'application sera rétracté localement, puis supprimée de tous les autres dossiers 'farming' des noeuds de serveur du cluster (ce qui déclenche la rétraction du déploiement). Vous devrez effacer manuellement les applications du dossier 'farming' de tout noeud de serv!
 eur qui n'est pas actuellement connecté au cluster."
+msgstr "La façon la plus simple de déployer une application dans le cluster est d'utiliser le service 'farming'. C'est pour déployer à chaud le fichier des archives de l'application (comme le fichier EAR, WAR ou SAR) dans le répertoire <code>all/farm/</code> de n'importe quel membre du cluster et l'application sera automatiquement dupliquée à travers les noeuds du même cluster. Si le noeud rejoint le cluster plus tard, toutes les applications 'farming' déployées seront attirées vers le cluster et elles seront déployées localement au démarrage. Si vous supprimez l'application d'un des dossiers <literal>farm/</literal> de noeud de serveur du groupement en cours d'exécution, le déploiement de l'application sera rétracté localement, puis supprimé de tous les autres dossiers 'farming' des noeuds de serveur du cluster (ce qui déclenche la rétraction du déploiement). Vous devrez effacer manuellement les applications du dossier 'farming' de tout noeud de serve!
 ur qui n'est pas actuellement connecté au cluster."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:217
@@ -864,7 +864,7 @@
 "connected to the HA-JNDI service on a particular JBoss AS instance, and that "
 "service fails or is shut down, the HA-JNDI client can transparently fail "
 "over to another AS instance."
-msgstr "Failover transparent des opérations de nommage. Si un contexte de nommage HA-JNDI est connecté au service HA-JNDI sur une instance JBoss AS particulière, et que le service échoue ou est fermé, le client HA-JNDI peut aller vers une autre instance de façon transparente."
+msgstr "Failover transparent des opérations de nommage. Si un contexte de nommage HA-JNDI est connecté au service HA-JNDI sur une instance JBoss AS particulière, et que le service échoue ou soit fermé, le client HA-JNDI peut aller vers une autre instance de façon transparente."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:296
@@ -919,7 +919,7 @@
 "to look up those proxies. However, it is important to understand that using "
 "HA-JNDI (or not) has no effect whatsoever on the clustering behavior of the "
 "objects that are looked up. To illustrate:"
-msgstr "JNDI est un composant clé de nombreux services de clustering basés-intercepteur : ces services s'enregistrent eux-même avec JNDI, de façon à ce que le client puisse chercher leur proxies et puisse utiliser leurs services. HA-JNDI complète le tableau en veillant à ce que les clients aient des moyens hautement disponibles pour chercher ces proxies. Cependant, il est important de comprendre qu'utiliser HA-JNDI (ou pas) n'a aucun effet sur le comportement du clustering des objets qu'on recherche. Pour illustrer ces propos: "
+msgstr "JNDI est un composant clé de nombreux services de clustering basés-intercepteur : ces services s'enregistrent eux-mêmes avec JNDI, de façon à ce que le client puisse chercher leur proxies et puisse utiliser leurs services. HA-JNDI complète le tableau en veillant à ce que les clients aient des moyens hautement disponibles pour chercher ces proxies. Cependant, il est important de comprendre qu'utiliser HA-JNDI (ou pas) n'a aucun effet sur le comportement du clustering des objets qu'on recherche. Pour illustrer ces propos :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:332
@@ -937,13 +937,13 @@
 "If an EJB is configured as clustered, looking up the EJB via regular JNDI "
 "instead of HA-JNDI does not somehow result in the removal of the bean "
 "proxy's clustering capabilities."
-msgstr "Si un EJB est configuré en tant que clusterisé, chercher EJB via le JNDI normal,au lieu d'HA-JNDI, ne résulte pas dans le retrait des capacités de clustering du proxy du bean."
+msgstr "Si un EJB est configuré en tant que clusterisé, chercher EJB via le JNDI normal, au lieu d'HA-JNDI, ne résulte pas dans le retrait des capacités de clustering du proxy du bean."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:347
 #, no-c-format
 msgid "How it works"
-msgstr "Comment ceal fonctionne-t-il ?"
+msgstr "Comment cela fonctionne-t-il ?"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:348
@@ -958,7 +958,7 @@
 "Other than the need to ensure the appropriate naming properties are provided "
 "to the InitialContext, the fact that the naming Context is using HA-JNDI is "
 "completely transparent to the client."
-msgstr "Le contexte de nommage HA-JNDI côté-client JBoss est basé sur l'architecture d'intercepteur côté-client. Le client obtient un objet proxy HA-JNDI (via l'objet InitialContext) et invoque les services de recherche JNDI sur le serveur distant, par l'intermédiaire du proxy. Le client précise qu'il souhaite un proxy HA-JNDI en configurant les propriétés de nommage utilisées par l'objet InitialContext. C'est couvert en détails dans la section \"Configuration Client\". Mis à part le besoin de s'assurer que les propriétés de nommage appropriées sont fournies à l'InitialContext, le fait que le Context de nommage utilise HA-JNDI est complètement transparent pour le client."
+msgstr "Le contexte de nommage HA-JNDI côté-client JBoss est basé sur l'architecture d'intercepteur côté-client. Le client obtient un objet proxy HA-JNDI (via l'objet InitialContext) et invoque les services de recherche JNDI sur le serveur distant, par l'intermédiaire du proxy. Le client précise qu'il souhaite un proxy HA-JNDI en configurant les propriétés de nommage utilisées par l'objet InitialContext. C'est couvert en détails dans la section \"Configuration Client\". Mis à part le besoin de s'assurer que les propriétés de nommage appropriées soient fournies à l'InitialContext, le fait que le Context de nommage utilise HA-JNDI est complètement transparent pour le client."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:351
@@ -988,7 +988,7 @@
 "In a homogeneous cluster, this configuration actually cuts down on the "
 "amount of network traffic. A homogenous cluster is one where the same types "
 "of objects are bound under the same names on each node."
-msgstr "Dans un cluster homogène, la configuration réduit en fait le volume de trafic sur le réseau. Un cluster homogène est un cluster pour lequel les mêmes types d'objets sont liés par les mêmes noms sur chaque noeud."
+msgstr "Dans un cluster homogène, la configuration réduit de fait le volume de trafic sur le réseau. Un cluster homogène est un cluster pour lequel les mêmes types d'objets sont liés par les mêmes noms sur chaque noeud."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:367
@@ -1042,7 +1042,7 @@
 "If not available, the HA-JNDI services asks all other nodes in the cluster "
 "if their local JNDI service owns such a binding and returns the answer from "
 "the set it receives."
-msgstr "Si non disponible, les services HA-JNDI vont demander à tous les autres noeuds du cluster si leur service JNDI local possède une telle liaison et retournera la réponse en fonction des informations qu'il reçoit."
+msgstr "Si elle n'est pas disponible, les services HA-JNDI vont demander à tous les autres noeuds du cluster si leur service JNDI local possède une telle liaison et retournera la réponse en fonction des informations qu'il recevra."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:390
@@ -1077,7 +1077,7 @@
 "the client is expecting to receive! So, it is always best practice to ensure "
 "that across the cluster different names are used for logically different "
 "bindings."
-msgstr "Snt des noms différents (même du même type, mais participant à différents clusters), utiliser le même nom JNDI, c'est à dire que chaque serveur JNDI aura une liaison de \"cible\" différente logiquement, JNDI aura, sur node 1, une liaison pour bean A et JNDI, sur node 2, aura une liaison, sous le même nom, pour bean B). Par conséquence, si un client lance une recherche HA-JNDI pour ce nom, la recherche sera invoquée sur n'importe quel serveur JNDI du cluster et va retourner le stub lié localement. Cependant, ce ne sera peut-être pas le stub que le client s'attend à recevoir! Donc, il vaut toujours mieux veiller à utiliser des noms différents à travers le cluster pour des liaisons différentes logiquement."
+msgstr "Si des beans distincts (même du même type, mais participant à différents clusters), utilisent le même nom JNDI, cela implique que chaque serveur JNDI aura une liaison de \"cible\" différente logiquement (JNDI aura, sur node 1, une liaison pour bean A et JNDI, sur node 2, aura une liaison, sous le même nom, pour bean B). Par conséquence, si un client lance une recherche HA-JNDI pour ce nom, la recherche sera invoquée sur n'importe quel serveur JNDI du cluster et va retourner le stub lié localement. Cependant, ce ne sera peut-être pas le stub que le client s'attend à recevoir! Donc, il vaut toujours mieux veiller à utiliser des noms différents à travers le cluster pour des liaisons différentes logiquement."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:406
@@ -1088,7 +1088,7 @@
 "JNDI federation using the ExternalContext MBean to bind non-JBoss JNDI trees "
 "into the JBoss JNDI namespace. Furthermore, nothing prevents you using one "
 "centralized JNDI server for your whole cluster and scrapping HA-JNDI and JNP."
-msgstr "Vous ne pouvez pas actuellement utiliser une implémentation non-JNP JNDI (c'est à dire LDAP) pour votre implémentation JNDI locale si vous souhaiter utiliser HA-JNDI. Cependant, vous pouvez utiliser la fédération JNDI, en utilisant le MBean ExternalContext pour lier les arborescences non-JBoss JNDI aux espaces de noms JBoss JNDI. De plus, rien ne vous empêche d'utiliser un des serveurs JNDI centralisé pour tout le groupement et se débarrasser de HA-JNDI et JNP."
+msgstr "Vous ne pouvez pas actuellement utiliser une implémentation non-JNP JNDI (c'est à dire LDAP) pour votre implémentation JNDI locale si vous souhaiter utiliser HA-JNDI. Cependant, vous pouvez utiliser la fédération JNDI, en utilisant le MBean ExternalContext pour lier les arborescences non-JBoss JNDI aux espaces de noms JBoss JNDI. De plus, rien ne vous empêche d'utiliser un des serveurs JNDI centralisé pour tout le groupement et de vous débarrasser de HA-JNDI et de JNP."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:412
@@ -1101,7 +1101,7 @@
 "to all nodes in the cluster. Consequently, the query time will be longer "
 "than if the binding would have been available locally. Moral of the story: "
 "as much as possible, cache the result of your JNDI queries in your client."
-msgstr "Si une liaison n'est rendue disponible que sur quelques noeuds du cluster (par exemple quand un bean n'est uniquement déployé que sur un petit sous-ensemble de noeuds du cluster), la probabilité pour une recherche de se heurter à un serveur HA-JNDI qui ne possède pas cette liaison, est plus élevée et par conséquence, la recherche aura besoin d'être redirigée vers tous les noeuds du cluster. Ainsi, le temps de recherche sera plus long que si la liaison avait été disponible localement. Moral de l'histoire : si possible, cacher le résultat de vos demandes JNDI dans votre client."
+msgstr "Si une liaison n'est rendue disponible que sur quelques noeuds du cluster (par exemple quand un bean n'est uniquement déployé que sur un petit sous-ensemble de noeuds du cluster), la probabilité pour une recherche de se heurter à un serveur HA-JNDI qui ne possède pas cette liaison, est plus élevée et par conséquence, la recherche aura besoin d'être redirigée vers tous les noeuds du cluster. Ainsi, le temps de recherche sera plus long que si la liaison avait été disponible localement. Morale de l'histoire : si possible, cacher le résultat de vos demandes JNDI dans votre client."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:420
@@ -1116,7 +1116,7 @@
 "for this name, the query will be invoked on any JNDI server of the cluster "
 "and will return the locally bound stub. Nevertheless, it may not be the "
 "correct stub that the client is expecting to receive!"
-msgstr "Donc, une recherche home EJB par HA-JNDI, sera toujours déléguée à l'instance JNDI locale. Si des beans différents (même du même type, mais participant à des clusters différents) utilisent le même nom JNDI, cela signifie que chaque serveur JNDI aura une \"cible\" différente liée (JNDI sur node 1 aura une liaison pour bean A et JNDI sur node 2 aura une liaison, sous le même, pour bean B). De ce fait, si un client effectue une demande HA-JNDI pour ce nom, la demande sera invoquée sur n'importe quel serveur JNDI du cluster et retournera le stub lié localement. Mais, le client ne s'attend peut-être pas à recevoir le stub correct!"
+msgstr "Donc, une recherche home EJB par HA-JNDI, sera toujours déléguée à l'instance JNDI locale. Si des beans différents (même du même type, mais participant à des clusters différents) utilisent le même nom JNDI, cela signifie que chaque serveur JNDI aura une \"cible\" différente liée (JNDI sur node 1 aura une liaison pour bean A et JNDI sur node 2 aura une liaison, sous le même, pour bean B). De ce fait, si un client effectue une demande HA-JNDI pour ce nom, la demande sera invoquée sur n'importe quel serveur JNDI du cluster et retournera le stub lié localement. Cependant, il pourrait ne pas s'agir du stub que le client s'attent à recevoir !"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:428
@@ -1203,7 +1203,7 @@
 "configuration, one approach is to deploy a properties file not named jndi."
 "properties, and then programatically create a Properties object that loads "
 "that file's contents."
-msgstr "Ne tentez pas de tout simplifier en ajoutant un fichier jndi.properties dans votre déploiement ou en modifiant le fichier d'AS conf/jndi.properties. Dans tous les cas, vous risquez d'endommager votre application, voire tout à travers le serveur d'applications. Si vous souhaitez externaliser la configuration de votre client, une approche consiste à déployer un fichier de propriétés qui n'est pas nommé jndi.properties, puis créer par un programme l'objet Properties qui charge le contenu de ce fichier."
+msgstr "Ne tentez pas de tout simplifier en ajoutant un fichier jndi.properties dans votre déploiement ou en modifiant le fichier d'AS conf/jndi.properties. Dans tous les cas, vous risquez d'endommager votre application, voire à travers tout le serveur d'applications. Si vous souhaitez externaliser la configuration de votre client, une approche consiste à déployer un fichier de propriétés qui n'est pas nommé jndi.properties, puis créer par un programme l'objet Properties qui charge le contenu de ce fichier."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:464
@@ -1222,7 +1222,7 @@
 "its IP address and the JNDI port number. The server nodes are separated by "
 "commas (see <xref linkend=\"clustering-jndi-jboss\"/> for how to configure "
 "the servers and ports)."
-msgstr "Le client JDI a besoin de connaître le cluster HA-JNDI. Vous pouvez passer une liste de serveurs JNDI (comme les noeuds du cluster HA-JNDI) aux paramètres JNDI <literal>java.naming.provider.url</literal> du fichier <literal>jndi.properties</literal>. Chaque noeud de serveur est identifié par son adresse IP et son nom de port JNDI. Les noeuds de serveurs sont séparés par des virgules (voir <xref linkend=\"clustering-jndi-jboss\"/> sur la façon de configurer les serveurs et les ports)."
+msgstr "Le client JNDI a besoin de connaître le cluster HA-JNDI. Vous pouvez passer une liste de serveurs JNDI (comme les noeuds du cluster HA-JNDI) aux paramètres JNDI <literal>java.naming.provider.url</literal> du fichier <literal>jndi.properties</literal>. Chaque noeud de serveur est identifié par son adresse IP et son nom de port JNDI. Les noeuds de serveurs sont séparés par des virgules (voir <xref linkend=\"clustering-jndi-jboss\"/> sur la façon de configurer les serveurs et les ports)."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:468
@@ -1238,7 +1238,7 @@
 "server node from the list, one after the other, stopping as soon as one "
 "server has been reached. It will then download the HA-JNDI stub from this "
 "node."
-msgstr "Quand vous initialisez, le code client tentera de rentrer en contact avec chaque noeud de serveur de la liste, l'un après l'autre, en s'arrêtant dès qu'un serveur est atteint. Il va ensuite décharger le stub HA-JNDI à partir de ce noeud."
+msgstr "Quand vous initialisez, le code client tentera d'entrer en contact avec chaque noeud de serveur de la liste, l'un après l'autre, en s'arrêtant dès qu'un serveur est atteint. Il va ensuite décharger le stub HA-JNDI à partir de ce noeud."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:473
@@ -1259,7 +1259,7 @@
 "if necessary. Furthermore, each time a JNDI invocation is made to the "
 "server, the list of targets in the proxy interceptor is updated (only if the "
 "list has changed since the last call)."
-msgstr "Le proxy smart déchargé contient la liste des noeuds actuellement en cours d'exécution et la logique pour équilibrer les recherches de noms ou pour effectuer une reprise sur un autre noeud si necessaire. De plus, à chaque fois qu'une invocation JNDI est effectuée sur le serveur, la liste des cibles de l'intercepteur proxy est mise à jour (seulement si la liste à été changée depuis le dernier appel)."
+msgstr "Le proxy smart déchargé contient la liste des noeuds actuellement en cours d'exécution, et la logique pour équilibrer les recherches de noms ou pour effectuer une reprise sur un autre noeud, si nécessaire. De plus, à chaque fois qu'une invocation JNDI est effectuée sur le serveur, la liste des cibles de l'intercepteur proxy est mise à jour (seulement si la liste à été changée depuis le dernier appel)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:480
@@ -1438,7 +1438,7 @@
 "value of the jboss.bind.address system property, or the host's default "
 "addresss if that property is not set. The jboss.bind.address system property "
 "is set if the -b command line switch is used when JBoss is started."
-msgstr "<emphasis role=\"bold\">BindAddress</emphasis> est un attribut optionnel qui spécifie l'adresse à laquelle le serveur HA-JNDI sera liée en attendant les clients JNP. Utile uniquement pour les ordinateurs multi-homed. La valeur par défaut est la valeur de propriété de système jboss.bind.address, ou l'adresse par défaut de l'hôte si cette propriété n'est pas déterminée. La propriété de système jboss.bind.address est fixée si le commutateur de ligne de commande -b est utilisé quand JBoss démarre."
+msgstr "<emphasis role=\"bold\">BindAddress</emphasis> est un attribut optionnel qui spécifie l'adresse à laquelle le serveur HA-JNDI sera liée en attendant les clients JNP. Utile uniquement pour les ordinateurs multi-homed. La valeur par défaut est la valeur de propriété de système jboss.bind.address, ou l'adresse par défaut de l'hôte, si cette propriété n'est pas déterminée. La propriété de système jboss.bind.address est fixée si le commutateur de ligne de commande -b est utilisé quand JBoss démarre."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:539
@@ -1486,7 +1486,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 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."
+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
@@ -1719,7 +1719,7 @@
 "e. any node that has this specific bean deployed) of the cluster. To make a "
 "bean clustered, you need to modify its <literal>jboss.xml</literal> "
 "descriptor to contain a <literal>&lt;clustered&gt;</literal> tag."
-msgstr "La session Beans sans état clusterisée est probablement le cas la plus simple : comme il n'y a pas d'état d'impliqué, les appels peuvent être équilibrés sur n'importe quel noeud participant (par ex., n'importe quel noeud qui a un Bean spécifique déployé) du groupement. Pour qu'un Bean soir clustérisé, vous aurez besoin de modifier son descripteur <literal>jboss.xml</literal> de façon à ce qu'il contienne une balise <literal>&lt;clusterisée&gt;</literal>."
+msgstr "La session Beans sans état clusterisée est probablement le cas le plus simple : comme il n'y a pas d'état d'impliqué, les appels peuvent être équilibrés sur n'importe quel noeud participant (par ex., n'importe quel noeud qui a un Bean spécifique déployé) du groupement. Pour qu'un Bean soir clustérisé, vous aurez besoin de modifier son descripteur <literal>jboss.xml</literal> de façon à ce qu'il contienne une balise <literal>&lt;clusterisée&gt;</literal>."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:608
@@ -1946,13 +1946,13 @@
 "interface are by default load-balanced, round-robin. Once the bean's remote "
 "stub is available to the client, calls will not be load-balanced round-robin "
 "any more and will stay \"sticky\" to the first node in the list."
-msgstr "La description des balises qui restent, est identique à celle de la session sans état Bean. Les actions sur l'interface d'accueil de la session à états cluterisée, sont par défaut équilibrées, par la méthode round-robin. Une fois que le module de remplacement éloigné du Bean est rendu disponible au client, les appels ne seront plus équilibrés 'round-robin'(méthode du tourniquet) et vont 'coller' (stay sticky) au premier noeud de la liste."
+msgstr "La description des balises qui restent, est identique à celle de la session sans état Bean. Les actions sur l'interface d'accueil de la session à états cluterisée, sont par défaut équilibrées par la méthode round-robin. Une fois que le module de remplacement éloigné du Bean est rendu disponible au client, les appels ne seront plus équilibrés 'round-robin'(méthode du tourniquet) et vont 'coller' (stay sticky) au premier noeud de la liste."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:665
 #, no-c-format
 msgid "Optimize state replication"
-msgstr "Optimise la reproduction d'états"
+msgstr "Optimiser la reproduction d'états"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:666
@@ -1980,7 +1980,7 @@
 "modified (or not enough to require replication, depending on your own "
 "preferences), you can return <literal>false</literal> and the replication "
 "would not occur. This feature is available on JBoss AS 3.0.1+ only."
-msgstr "Avant de reproduire votre Bean, le conteneur détectera si votre Bean peut implémenter cette méthode. Si c'est le cas, le conteneur appelle la méthode <literal>isModified()</literal> et ne reproduit le Bean que quand la méthode retourne <literal>true</literal> (vrai). Si le Bean n'a pas été modifié (ou pas au point d'avoir besoin d'une reproduction, suivant vos propres préférences), alors vous pouvez retourner <literal>false</literal> (faux) et la reproduction n'aura pas lieu. Cette fonctionnalité est disponible sur JBoss AS 3.0.1+ uniquement."
+msgstr "Avant de reproduire votre Bean, le conteneur détectera si votre Bean peut implémenter cette méthode. Si c'est le cas, le conteneur appelle la méthode <literal>isModified()</literal> et ne reproduit le Bean que quand la méthode retourne <literal>true</literal> (vrai). Si le Bean n'a pas été modifié (ou pas au point d'avoir besoin d'une reproduction, suivant vos propres préférences), alors vous pourrez retourner <literal>false</literal> (faux) et la reproduction n'aura pas lieu. Cette fonctionnalité est disponible sur JBoss AS 3.0.1+ uniquement."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:677
@@ -2083,7 +2083,7 @@
 "sometimes. The default value is <literal>30*60*1000</literal> milliseconds "
 "(i.e., 30 minutes)."
 msgstr ""
-"<emphasis role=\"bold\">BeanCleaningDelay</emphasis> est un attribut optionnel qui spécifie le nombre de millesecondes après lesquelles le service <literal>HASessionState</literal> peut nettoyer un état qui n'a pas été modifié. Si un noeud, qui comprend un Bean, se plante, son noeud frère deviendra propriétaire de ce Bean. Cependant, le conteneur cache du noeud frère se sera pas au courant (car il ne l'a jamais vu auparavant) et n'efface jamais suivant les paramètres de nettoyage du Bean. C'est pourquoi le service <literal>HASessionState</literal> a besoin d'effectuer ce nettoyage de temps en temps. La valeur par défaut est de <literal>30*60*1000</literal> millisecondes "
+"<emphasis role=\"bold\">BeanCleaningDelay</emphasis> est un attribut optionnel qui spécifie le nombre de millesecondes après lesquelles le service <literal>HASessionState</literal> peut nettoyer un état qui n'a pas été modifié. Si un noeud, qui comprend un Bean, se plante, son noeud frère deviendra propriétaire de ce Bean. Cependant, le conteneur cache du noeud frère se sera pas au courant (car il ne l'a jamais vu auparavant) et n'efface jamais en fonction des paramètres de nettoyage du Bean. C'est pourquoi le service <literal>HASessionState</literal> a besoin d'effectuer ce nettoyage de temps en temps. La valeur par défaut est de <literal>30*60*1000</literal> millisecondes "
 "(c'est à dire, 30 minutes)."
 
 #. Tag: title
@@ -2103,7 +2103,7 @@
 "the available nodes in the cluster. There is no way for the proxy to recover "
 "from this. The proxy needs to look up a fresh set of targets out of JNDI/"
 "HAJNDI when the nodes are restarted."
-msgstr "Nous avons couvert l'architecture HA smart client dans la section intitulée “Client-side interceptor architecture”. Le client par défaut HA smart proxy ne peut échouer tant qu'un noeud existe dans le groupement. S'il y a une fermeture complète du groupement, le proxy devient orphelin et perd sa connaissance des noeuds disponibles dans le groupement. Il n'y a aucun moyen de se rétablir suite à ce problème. Le proxy a besoin de chercher un nouvel ensemble de cibles en dehors de JNDI/HAJNDI quand les noeuds sont redémarrés."
+msgstr "Nous avons couvert l'architecture HA smart client dans la section intitulée “Client-side interceptor architecture”. Le client par défaut HA smart proxy ne peut échouer tant qu'un noeud existe dans le groupement. S'il y a une fermeture complète du groupement, le proxy devient orphelin et perd sa connaissance des noeuds disponibles dans le groupement. Il n'y a aucun moyen pour se rétablir par la suite. Le proxy a besoin de chercher un nouvel ensemble de cibles en dehors de JNDI/HAJNDI quand les noeuds sont redémarrés."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:711
@@ -2269,7 +2269,7 @@
 "to configuration has two downsides: first, it reduces portability by "
 "introducing JBoss-specific calls to the client code; and second, since a "
 "static field is used only a single configuration per JVM is possible."
-msgstr "Il vérifiera son propre champs statique retryEnv. Ce champ peut être déterminé grâce à un code client suite à un appel à RetryInterceptor.setRetryEnv(Properties). Cette approche de configuration comporte deux cas de figure: tout d'abord, cela réduit la portabilité en introduisant des appels JBoss-specific vers le code client, et deuxièmement, comme un champ static est utilisé, on ne peut avoir qu'une seule configuration par JMV. "
+msgstr "Il vérifiera son propre champ statique retryEnv. Ce champ peut être déterminé grâce à un code client, suite à un appel à RetryInterceptor.setRetryEnv(Properties). Cette approche de configuration comporte deux cas de figure: tout d'abord, cela réduit la portabilité en introduisant des appels JBoss-specific vers le code client, et deuxièmement, comme un champ statique est utilisé, on ne peut avoir qu'une seule configuration par JMV. "
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:728
@@ -2536,7 +2536,7 @@
 "true, since replication involves serializing the bean, and preparing for and "
 "recovering from serialization is a common reason for implementing the "
 "callback methods."
-msgstr "<literal>replicationIsPassivation</literal> spécifie si le cache devrait considérer qu'une réplication est équivalente à une passivation, et invoquer n'importe quels appels @PrePassivate and @PostActivate sur le Bean. Vrai (true) par défaut, puisque la reproduction implique la sérialisation du Bean, préparer et se rétablir après sérialisation, c'est une raison courante pour implémenter les méthodes callaback."
+msgstr "<literal>replicationIsPassivation</literal> spécifie si le cache devrait considérer qu'une réplication est équivalente à une passivation, et invoquer n'importe quels appels @PrePassivate and @PostActivate sur le Bean. Vrai (true) par défaut, puisque la reproduction implique la sérialisation du Bean, préparer et se rétablir après sérialisation, c'est une raison courante pour implémenter les méthodes callback."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:799
@@ -2811,7 +2811,7 @@
 "discussed in <xref linkend=\"jbosscache.chapt\"/>. Again, we omitted the "
 "JGroups configurations in the <literal>ClusterConfig</literal> attribute "
 "(see more in <xref linkend=\"jbosscache-jgroups\"/>). Two noteworthy items:"
-msgstr "Les attributs de configuration de ce MBean sont principalement les mêmes que les attributs du MBean JBoss Cache standard <literal>TreeCache</literal> expliqué dans <xref linkend=\"jbosscache.chapt\"/>. Nous avons à nouveau omis les configurations JGroups de l'attribut <literal>ClusterConfig</literal> (voir davantage d'informations dans <xref linkend=\"jbosscache-jgroups\"/>). Deux points importants :"
+msgstr "Les attributs de configuration de ce MBean sont principalement les mêmes que les attributs du MBean JBoss Cache standard <literal>TreeCache</literal>, comme expliqués dans <xref linkend=\"jbosscache.chapt\"/>. Nous avons à nouveau omis les configurations JGroups de l'attribut <literal>ClusterConfig</literal> (voir davantage d'informations dans <xref linkend=\"jbosscache-jgroups\"/>). Deux points importants :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:851
@@ -2844,7 +2844,7 @@
 #: Clustering_Guide_Introduction.xml:865
 #, no-c-format
 msgid "Clustered Entity EJBs"
-msgstr "<literal>persistence.xml</literal>Entités EJB clusterisées"
+msgstr "Entités Bean EJBs"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:866
@@ -2977,7 +2977,7 @@
 "<ulink url=\"http://dima.dhs.org/misc/readOnlyUpdates.html\"></ulink>. JBoss "
 "may incorporate this pattern into later versions.)"
 msgstr ""
-"Cependant, les entités Bean EJB 2.x ne possèdent pas un mécanisme de verrouillage distribué ou un cache distribué. Elles peuvent uniquement être synchronisées en utilisant le verrouillage au niveau-rangée de la base de données (voir <literal>&lt;row-lock&gt;</literal> dans les spécifications CMP ) ou bien en paramétrant les niveaux d'isolation de transactions du pilote JDBC pour qu'il soit <literal>TRANSACTION_SERIALIZABLE</literal>. En effet, il n'y a pas de mécanisme de verrouillage distribué supporté ou d'entités Bean cache distribuées utilisant l'option Commit (validation) \"B\" par défaut (Voir <literal>standardjboss.xml</literal> et les configurations de conteneur <literal>standardjboss."
+"Cependant, les entités Bean EJB 2.x ne possèdent pas un mécanisme de verrouillage distribué ou un cache distribué. Elles peuvent uniquement être synchronisées en utilisant le verrouillage au niveau-rangée de la base de données (voir <literal>&lt;row-lock&gt;</literal> dans les spécifications CMP ) ou bien en paramétrant les niveaux d'isolation de transactions du pilote JDBC pour qu'il soit <literal>TRANSACTION_SERIALIZABLE</literal>. En effet, il n'y a pas de mécanisme de verrouillage distribué supporté ou d'entités Bean cache distribuées utilisant l'option Commit (validation) \"B\" par défaut (voir <literal>standardjboss.xml</literal> et les configurations de conteneur <literal>standardjboss."
 "xml</literal>). Il n'est pas conseillé d'utiliser l'option Commit \"A\" à moins que l'entité Bean soit en lecture-seule. (Il y a des modèles qui vous permettent d'utiliser l'option Commit \"A\" pour les Beans lecture-surtout. Vous pouvez également jeter un oeil sur le modèle Seppuku <ulink url=\"http://dima.dhs.org/misc/readOnlyUpdates.html\"></ulink>. JBoss incorporera peut-être ce modèle dans des versions à venir)."
 
 #. Tag: para
@@ -3039,7 +3039,7 @@
 msgid ""
 "If you update an entity bean instance and save the changes to the database "
 "via the entity manager the entity will updated in the cache."
-msgstr "Si vous mettez à jour une instance d'entité Bean, et que vous sauvegardez les changements dans la base de donnée par le gestionnaire d'entités, l'entité sera mise à jour dans le cache."
+msgstr "Si vous mettez à jour une instance d'entité Bean, et que vous sauvegardez les changements dans la base de données par le gestionnaire d'entités, l'entité sera mise à jour dans le cache."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:917
@@ -3210,7 +3210,7 @@
 "values of 5000 maxNodes and 1000 idle seconds are invalid for your "
 "application(s), you can change the cache-wide defaults. You can also add "
 "separate eviction regions for each of your entities; more on this below."
-msgstr "JBoss vous permet d'indiquer les délais de non activité aux entités cache. Les entités qui ne sont pas visitées pendant un certain temps, sont rejetées du cache, afin de préserver la mémoire. La configuration ci-dessus définit une région de configuration par défaut qui indique qu'au plus le cache comprendra 5000 noeuds, et qu'ensuite, les noeuds seront expulsés de la mémoire, avec les noeuds les moins utilisés récemment en dernier. Aussi, si un noeud n'a pas été visité pendant les dernières 1000 secondes, il sera expulsé de la mémoire. En général, un noeud du cache représente un élément caché (entité, collection ou résultat de recherche), quoi qu'il existe quelques autres noeuds qui sont utilisés dans des desseins internes. Si la valeur ci-dessus de 5000 maxNodes et de 1000 secondes sans activité, sont invalides pour votre application, vous pourrez changer les valeurs par défaut dans l'ensemble du cache. Vous pourrez également ajoute!
 r des régions d'éviction séparées pour chacune de vos entités; voir ce qui suit à ce sujet ci-dessous."
+msgstr "JBoss vous permet d'indiquer les délais de non activité aux entités cache. Les entités qui ne sont pas visitées pendant un certain temps, seront rejetées du cache, afin de préserver la mémoire. La configuration ci-dessus définit une région de configuration par défaut qui indique, qu'au plus, le cache comprendra 5000 noeuds, et qu'ensuite, les noeuds seront expulsés de la mémoire, avec les noeuds les moins utilisés récemment en dernier. Aussi, si un noeud n'a pas été visité pendant les dernières 1000 secondes, il sera expulsé de la mémoire. En général, un noeud du cache représente un élément caché (entité, collection ou résultat de recherche), quoi qu'il existe quelques autres noeuds qui sont utilisés dans des desseins internes. Si la valeur ci-dessus de 5000 maxNodes et de 1000 secondes sans activité, sont invalides pour votre application, vous pourrez changer les valeurs par défaut dans l'ensemble du cache. Vous pourrez également aj!
 outer des régions d'éviction séparées pour chacune de vos entités; voir ce qui suit à ce sujet ci-dessous."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:940
@@ -3301,7 +3301,7 @@
 "prefix. This is not a particularly friendly region prefix if you need to use "
 "it to set up specialized eviction regions (see below), so specifying your "
 "own region prefix is recommended."
-msgstr "Si vous ne fournissez pas de préfixe régional, JBoss va automatiquement vous en fournir un, en le construisant à partir du nom d'EAR (s'il existe) et le nom du JAR qui inclut la persistence.xml. AInsi, une persistence.xml présente dans foo.ear, bar.jar aura foo_ear,bar_jar” comme préfixe régional. Ce n'est pas un préfixe de région particulièrement facile si vous avez besoin de l'utiliser pour installer les régions d\"éviction (voir ci-dessous). Nous vous conseillons donc de déterminer votre propre préfixe régional."
+msgstr "Si vous ne fournissez pas de préfixe régional, JBoss va automatiquement vous en fournir un, en le construisant à partir du nom d'EAR (s'il existe) et le nom du JAR qui inclut la persistence.xml. Ainsi, une persistence.xml présente dans foo.ear, bar.jar, aura “foo_ear,bar_jar” comme préfixe régional. Ce n'est pas un préfixe de région particulièrement facile si vous avez besoin de l'utiliser pour installer les régions d\"éviction (voir ci-dessous). Nous vous conseillons donc de déterminer votre propre préfixe régional."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:965
@@ -3424,7 +3424,7 @@
 "that lets you specify the cache region where an entity is to be stored, "
 "rather than having it be automatically be created from the fully-qualified "
 "class name of the entity class."
-msgstr "Si vous ne précisez pas une région cache pour une classe d'entité Bean, toutes les instances de cette classe seront cachées dans la région <literal>/_default</literal> comme déterminée ci-dessus. L'annotation @Cache expose une attribut optionnel \"region\" qui vous laisse spécifier la région cache dans laquelle on peut stocker une entité qui vous laissera spécifier la région cache dans laquelle l'entité pourra être stockée, plutôt que de l'avoir automatiquement créée à partir d'un nom de classe complet de la classe de l'entité."
+msgstr "Si vous ne précisez pas une région cache pour une classe d'entité Bean, toutes les instances de cette classe seront cachées dans la région <literal>/_default</literal> comme déterminée ci-dessus. L'annotation @Cache expose une attribut optionnel \"region\" qui vous laisse spécifier la région cache dans laquelle on peut stocker une entité qui vous laissera spécifier la région cache dans laquelle l'entité pourra être stockée, au lieu qu'elle soit automatiquement créée à partir d'un nom de classe complet de la classe de l'entité."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:975
@@ -3519,7 +3519,7 @@
 "collections of scalar values) of specified queries. Here we show a simple "
 "example of annotating a bean with a named query, also providing the "
 "Hibernate-specific hints that tells Hibernate to cache the query."
-msgstr "L'API EJB3 Query vous donne également les moyens de sauvegarder les résultats cache de second-niveau (c'est à dire, les clés primaires d'entités Bean, ou les collections de valeurs scalaires) de demandes précises. Nous allons vous montrer ci-dessous un simple exemple d'annotation d'un Bean qui comporte une demande associéé à une dénomination précise, tout en fournissant les indications particulières à Hibernate, qui instruit Hibernate de cacher la recherche."
+msgstr "L'API EJB3 Query vous donne également les moyens de sauvegarder les résultats cache de second-niveau (c'est à dire, les clés primaires d'entités Bean, ou les collections de valeurs scalaires) de demandes précises. Nous allons vous montrer ci-dessous un simple exemple d'annotation d'un Bean qui comporte une demande associée à une dénomination précise, tout en fournissant les indications particulières à Hibernate qui instruisent Hibernate de cacher la recherche."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:986
@@ -3591,7 +3591,7 @@
 "can set up separate eviction handling for your query results. So, if the "
 "region prefix were set to myprefix in persistence.xml, you could, for "
 "example, create this sort of eviction handling:"
-msgstr "Par défaut, Hibernate stocke les résultats de recherche dans JBoss Cache dans une région nommé {region_prefix}/org/hibernate/cache/StandardQueryCache. Sur cette base, vous pourrez installer un système de gestion des évictions séparé pour les résultats de vos recherches. Ainsi, si le préfixe régional est paramétré myprefix dans persistence.xml, vous pourriez, par exemple, créer ce système de gestion des évictions :"
+msgstr "Par défaut, Hibernate stocke les résultats de recherche dans JBoss Cache dans une région nommée {region_prefix}/org/hibernate/cache/StandardQueryCache. Sur cette base, vous pourrez installer un système de gestion des évictions séparé pour les résultats de vos recherches. Ainsi, si le préfixe régional est paramétré myprefix dans persistence.xml, vous pourriez, par exemple, créer ce système de gestion d'évictions :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1002
@@ -3852,7 +3852,7 @@
 "example) or by specialized software running on commodity hardware. As a very "
 "common scenario, we will demonstrate how to set up a software load balancer "
 "using Apache httpd and mod_jk."
-msgstr "Cependant, l'équilibrage des charges est un problème qui n'est pas du ressort de JBoss et requiert un équilibreur de charges externe. Cette fonction pourrait être offerte par des commutateurs spécialisés ou par des routeurs (comme Cisco LoadDirector par exemple) ou par des logiciels spécialisés exécutables sur du matériel de base. Sur la base d'un scénario courant, nous allons montrer comment installer un équilibreur de charge informatique en utilisant Apache httpd et mod_jk."
+msgstr "Cependant, l'équilibrage des charges est un problème qui n'est pas du ressort de JBoss et qui requiert un équilibreur de charges externe. Cette fonction pourrait être offerte par des commutateurs spécialisés ou par des routeurs (comme Cisco LoadDirector par exemple) ou par des logiciels spécialisés exécutables sur du matériel de base. Sur la base d'un scénario courant, nous allons montrer comment installer un équilibreur de charges informatique en utilisant Apache httpd et mod_jk."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1063
@@ -3872,7 +3872,7 @@
 "not to replicate HTTP sessions because all critical state is stored in a "
 "database. In other situations, losing a client session is not acceptable "
 "and, in this case, session state replication is the price one has to pay."
-msgstr "Un équilibreur de charges suit les demandes HTTP, et, suivant la session à laquelle la demande est liée, il dirige la demande vers le noeud qui convient. On appelle cela l'équilibrage des charges à sticky sessions (affinités de sessions): une fois qu'une session est créée sur un noeud, toute future demande sera traitée par ce même noeud. Si vous utilisez un équilibreur de charges qui supporte les sticky sessions, sans configurer votre application Web pour la réplication des sessions, vous permet un bon équilibrage, tout en évitant le coût d'une réplication d'états de session : chaque demande sera toujours traitée par le même noeud. Dans le cas où un noeud meurt, l'état de toutes les sessions client liées à ce noeud (comme les paniers d'achat par exemple) sera perdu et les clients auront probablement besoin de se connecter à un autre noeud. Dans de nombreuses situations, il est acceptable de ne pas reproduire les sessions HTTP, car tout état !
 critique est stocké dans une base de données. Dans d'autres situations, il n'est pas acceptable de perdre une session client, et, dans ce cas, la réplication des états de session est le prix à payer."
+msgstr "Un équilibreur de charges suit les demandes HTTP, et, suivant la session à  laquelle la demande est liée, il dirige la demande vers le noeud qui convient. On appelle cela l'équilibrage des charges à  sticky sessions (affinités de sessions): une fois qu'une session est créée sur un noeud, toute future demande sera traitée par ce même noeud. Si vous utilisez un équilibreur de charges qui supporte les sticky sessions, sans configurer votre application Web pour la réplication des sessions, cela vous permet un bon équilibrage, tout en évitant le coût d'une réplication d'états de session : chaque demande sera toujours traitée par le même noeud. Dans le cas où un noeud meurt, l'état de toutes les sessions client liées à  ce noeud (comme les paniers d'achat par exemple) sera perdu et les clients auront probablement besoin de se connecter à  un autre noeud. Dans de nombreuses situations, il est acceptable de ne pas reproduire les sessions HTTP, car tout Ã!
 ©tat critique est stocké dans une base de données. Dans d'autres situations, il n'est pas acceptable de perdre une session client, et, dans ce cas, la réplication des états de session est le prix à  payer."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1065
@@ -3890,7 +3890,7 @@
 "Furthermore, it is also able to load-balance HTTP calls to a set of Servlet "
 "containers while maintaining sticky sessions, which is what is most "
 "interesting for us in this section."
-msgstr "Apache est une serveur Web bien connu, qui peut être extensible grâce à l'addition de plugins dans des modules. Un de ces modules, mod_jk, a été spécialement conçu pour permettre le redirection de demandes à partir d'Apache vers une conteneur de servlet. De plus, il est également capable d'équilibrer les appels HTTP vers un ensemble de conteneurs servlet, tout en conservant les sticky sessions, ce qui nous intéresse dans cette section."
+msgstr "Apache est une serveur Web bien connu, qui peut être extensible grâce à l'addition de plugins dans des modules. Un de ces modules, mod_jk, a été spécialement conçu pour permettre la redirection de demandes à partir d'Apache vers une conteneur de servlet. De plus, il est également capable d'équilibrer les appels HTTP vers un ensemble de conteneurs servlet, tout en conservant les sticky sessions, ce qui nous intéresse dans cette section."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1072
@@ -4078,7 +4078,7 @@
 "loadbalancer for Java applications. If you only use mod_jk as a "
 "loadbalancer, you can also forward all URLs (i.e., <literal>/*</literal>) to "
 "mod_jk."
-msgstr "La directive <literal>LoadModule</literal> indique à Apache vers quels URL, il doit envoyer le module mod_jk (puis, aux conteneurs Servlet, à leur tour). Dans le fichier ci-dessus, toutes les demandes qui comprennent le chemin d'accés <literal>/application/*</literal> sont envoyées vers l'équilibreur des charges mod_jk. Ainsi, vous pouvez configurer Apache aux contenus statiques du serveur (ou contenus PHP) directement, et cantonner l'utilisation de l'équilibreur des charges aux applications Java. Si vous n'utilisez mod_jk qu'en tant qu'équilibreur des charges, vous pourrez alors rediriger tous les URL  (c'est à dire  <literal>/*</literal>) vers mod_jk."
+msgstr "La directive <literal>LoadModule</literal> indique à Apache vers quels URL, il doit envoyer le module mod_jk (puis, aux conteneurs Servlet, à leur tour). Dans le fichier ci-dessus, toutes les demandes qui comprennent le chemin d'accés <literal>/application/*</literal> sont envoyées vers l'équilibreur des charges mod_jk. Ainsi, vous pouvez configurer Apache avec les contenus statiques du serveur (ou contenus PHP) directement, et cantonner l'utilisation de l'équilibreur des charges aux applications Java. Si vous n'utilisez mod_jk qu'en tant qu'équilibreur des charges, vous pourrez alors rediriger tous les URL  (c'est à dire  <literal>/*</literal>) vers mod_jk."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1107
@@ -4091,7 +4091,7 @@
 "the <literal>APACHE_HOME/conf</literal> directory. The format of the file is "
 "<literal>/url=worker_name</literal>. To get things started, paste the "
 "following example into the file you created:"
-msgstr "En plus de la directive <literal>JkMount</literal>, vous pouvez également utiliser la directive <literal>JkMountFile</literal> pour spécifier un fichier de configuration des points de montage qui contiet un Tomcat multiple, redirigeant les mappages URL. Vous aurez juste besoin de créer un fichier <literal>uriworkermap.properties</literal> au sein du répertoire <literal>APACHE_HOME/conf</literal>. Le format du fichier est <literal>/url=worker_name</literal>. Pour commencer, coller l'exemple suivant dans le fichier que vous avez créé :"
+msgstr "En plus de la directive <literal>JkMount</literal>, vous pouvez également utiliser la directive <literal>JkMountFile</literal> pour spécifier un fichier de configuration des points de montage qui contienne un Tomcat multiple, redirigeant les mappages URL. Vous aurez juste besoin de créer un fichier <literal>uriworkermap.properties</literal> au sein du répertoire <literal>APACHE_HOME/conf</literal>. Le format du fichier est <literal>/url=worker_name</literal>. Pour commencer, collez l'exemple suivant dans le fichier que vous avez créé :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1113
@@ -4223,7 +4223,7 @@
 "Basically, the above file configures mod_jk to perform weighted round-robin "
 "load balancing with sticky sessions between two servlet containers (JBoss "
 "Tomcat) node1 and node2 listening on port 8009."
-msgstr "SImplement, le fichier ci-dessus configure mod_jk pour qu'il puisse effectuer l'équilibrage des charges de manière Weighted Round-Robin (en tourniquet) par sticky sessions entre deux conteneurs de servlets (JBoss Tomcat) node1 et node branchés sur le port 8009."
+msgstr "Simplement, le fichier ci-dessus configure mod_jk pour qu'il puisse effectuer l'équilibrage des charges de manière Weighted Round-Robin (en tourniquet) par sticky sessions entre deux conteneurs de servlets (JBoss Tomcat) node1 et node2 branchés sur le port 8009."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1130
@@ -4260,7 +4260,7 @@
 "of the Servlet container. Please review <literal>http://jakarta.apache.org/"
 "tomcat/connectors-doc/config/workers.html</literal> for comments on "
 "<literal>cachesize</literal> for Apache 1.3.x."
-msgstr "L'attribut <literal>cachesize</literal> détermine la taille des thread pools associées au conteneur du servlet (c'est à dire le nombre de demandes concurrentes qu'il enverra au conteneur du servlet). Veillez bien à ce que ce nombre de dépasse pas le nombre de threads qui sont configurés sur le connecteur AJP13 du conteneur de servlet. Consulter à nouveau <literal>http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html</literal> pour voir les commentaires <literal>cachesize</literal> applicables à Apache 1.3.x."
+msgstr "L'attribut <literal>cachesize</literal> détermine la taille des threads pools associés au conteneur du servlet (c'est à dire le nombre de demandes concurrentes qu'il enverra au conteneur du servlet). Veillez bien à ce que ce nombre de dépasse pas le nombre de threads qui sont configurés sur le connecteur AJP13 du conteneur de servlet. Consultez à nouveau <literal>http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html</literal> pour voir les commentaires <literal>cachesize</literal> applicables à Apache 1.3.x."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1143
@@ -4287,7 +4287,7 @@
 "the client is always using the same server he reached on his first request. "
 "To enable session stickiness, you need to set <literal>worker.loadbalancer."
 "sticky_session</literal> to 1."
-msgstr "La propriété <literal>sticky_session</literal> spécifie le comportement du cluster pour les sessions HTTP. Si vous spécifiez <literal>worker.loadbalancer.sticky_session=0</literal>, chaque demande sera équilibrée entre node1 et node2, c'est à dire, que différentes demandes iront vers différents serveurs pour une même session. Mais quand un utilisateur ouvre une session sur un serveur, il est toujours nécessaire de renvoyer les demandes de cet utilisateur vers le même serveur, tant que ce serveur reste disponible. C'est ce qu'on appelle une sitcky session, car le client utilise toujours le même serveur que celui qu'il a atteint pour sa première demande. Pour activer sticky session, vous aurez besoin de paramétrer <literal>worker.loadbalancer.sticky_session</literal> à 1."
+msgstr "La propriété <literal>sticky_session</literal> spécifie le comportement du cluster pour les sessions HTTP. Si vous spécifiez <literal>worker.loadbalancer.sticky_session=0</literal>, chaque demande sera équilibrée entre node1 et node2, c'est à dire que différentes demandes iront vers différents serveurs pour une même session. Mais quand un utilisateur ouvre une session sur un serveur, il est toujours nécessaire de renvoyer les demandes de cet utilisateur vers le même serveur, tant que ce serveur reste disponible. C'est ce qu'on appelle une sitcky session, car le client utilise toujours le même serveur que celui qu'il a atteint pour sa première demande. Pour activer sticky session, vous aurez besoin de paramétrer <literal>worker.loadbalancer.sticky_session</literal> à 1."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1152
@@ -4324,8 +4324,8 @@
 "your own server name if necessary). Locate the <literal>&lt;Engine&gt;</"
 "literal> element and add an attribute <literal>jvmRoute</literal>:"
 msgstr ""
-"Sur chaque noeud JBoss clusterisé, nous devons nommer le noeud en fonction du nom qui est précisé dans <literal>workers.properties</literal>. Ainsi, dans l'instance JBoss node1, éditer le fichier <literal>JBOSS_HOME/server/all/deploy/jboss-web.deployer/server.xml</literal> (remplacer <literal>/all</literal> par le nom de votre propre serveur, si nécessaire). Localiser l'élément <literal>&lt;Engine&gt;</"
-"literal> et ajouter l'attribut <literal>jvmRoute</literal> :"
+"Sur chaque noeud JBoss clusterisé, nous devons nommer le noeud en fonction du nom qui est précisé dans <literal>workers.properties</literal>. Ainsi, dans l'instance JBoss node1, éditez le fichier <literal>JBOSS_HOME/server/all/deploy/jboss-web.deployer/server.xml</literal> (remplacer <literal>/all</literal> par le nom de votre propre serveur, si nécessaire). Localisez l'élément <literal>&lt;Engine&gt;</"
+"literal> et ajoutez l'attribut <literal>jvmRoute</literal> :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1165
@@ -4380,10 +4380,10 @@
 "literal> element with a name of <literal>UseJK</literal>, and set its value "
 "to <literal>true</literal>:"
 msgstr ""
-"Ensuite, pour chaque instance JBoss Yomcat du cluster, nous devrons lui notifier que mod_jk est en cours d'utilisation, de façon à se qu'il puisse convenablement s'occuper de <literal>jvmRoute</literal> annexé à ses cookies de session, et de façon à ce que mod_jk puisse rediriger correctement les demandes en cours. Editez le fichier <literal>JBOSS_HOME/server/all/deploy/jbossweb-tomcat50."
+"Ensuite, pour chaque instance JBoss Yomcat du cluster, nous devrons lui notifier que mod_jk est en cours d'utilisation, de façon à ce qu'il puisse convenablement s'occuper de <literal>jvmRoute</literal> qui est annexé à ses cookies de session, et de façon à ce que mod_jk puisse rediriger correctement les demandes en cours. Editez le fichier <literal>JBOSS_HOME/server/all/deploy/jbossweb-tomcat50."
 "sar/META-INF/jboss-service.xml</literal> (remplacer <literal>/all</"
 "literal> par votre propre nom de serveur). Localiser l'élément <literal>&lt;attribute&gt;</"
-"literal> avec un nom de<literal>UseJK</literal>, et en fixer la valeur à <literal>true</literal> (vrai):"
+"literal> avec un nom de<literal>UseJK</literal>, et en fixer la valeur à <literal>true</literal> (vrai) :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1175
@@ -4438,7 +4438,7 @@
 "data is lost. A better and more reliable solution is to replicate session "
 "data across the nodes in the cluster. This way, the client can hit any "
 "server node and obtain the same session state."
-msgstr "Dans <xref linkend=\"clustering-http-nodes\"/>, nous avons couvert la façon d'utiliser les sticky sessions afin qu'au cours d'une session, un client donné fasse toujours appel au même noeud de serveur pour maintenir l'état de session. Cependant, les sticky sessions ne sont pas, en elles-mêmes, des solutions idéales. Si un noeud échoue, toutes ses données de session sont perdues. Une solution plus fiable consiste à reproduire les données de session à travers tous les noeuds du cluster. De cette façon, le client peut faire appel à n'importe quel noeud du serveur, et obtenir le même état de session."
+msgstr "Dans <xref linkend=\"clustering-http-nodes\"/>, nous avons couvert la façon d'utiliser les sticky sessions afin qu'au cours d'une session, un client donné fasse toujours appel au même noeud de serveur pour maintenir l'état de session. Cependant, les sticky sessions ne sont pas, en elles-mêmes, des solutions idéales. Si un noeud échoue, toutes ses données de session seront perdues. Une solution plus fiable consiste à reproduire les données de session à travers tous les noeuds du cluster. De cette façon, le client peut faire appel à n'importe quel noeud du serveur, et obtenir le même état de session."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1194
@@ -4554,7 +4554,7 @@
 "(covered below) needs the added features of the <literal>TreeCacheAop</"
 "literal> (a.k.a. <literal>PojoCache</literal>) class."
 msgstr ""
-"Notez que la valeur de l'attribut de code d'élément mbean est org.jboss.cache.aop.TreeCacheAop, ce qui est différent des autres MBeans JBoss Cache utilisés dans JBoss AS. C'est parce que la réplication de sessions HTTP granularity FIELD (couvert ci-dessous) a besoin des fonctionnalités supplémentaires la la classe <literal>TreeCacheAop</"
+"Notez que la valeur de l'attribut de code d'élément mbean est org.jboss.cache.aop.TreeCacheAop, ce qui est différent des autres MBeans JBoss Cache utilisés dans JBoss AS. C'est parce que la réplication de sessions HTTP granularity FIELD (couvert ci-dessous) a besoin des fonctionnalités supplémentaires de la classe <literal>TreeCacheAop</"
 "literal> (ou <literal>PojoCache</literal>)."
 
 #. Tag: para
@@ -4594,7 +4594,7 @@
 "Using synchronous replication makes sure changes are applied aroundthe "
 "cluster before the web request completes. However, synchronous replication "
 "is much slower."
-msgstr "<emphasis role=\"bold\">CacheMode</emphasis> contrôle la manière dont le cache est reproduit. Les valeurs valides sont <literal>REPL_SYNC</literal> et <literal>REPL_ASYNC</literal>. Quel que soit le cas de figure, le thread de demande en provenance du client, met à jour le cache local des contenus de sessions courantes, puis envoie un message vers les caches des autres membres du cluster, en les instruisant de procéder au même changement. Avec REPL_ASYNC (par défaut) le thread de demande retourne dès que le message mis à jour a été posté sur le réseau. Avec REPL_SYNC, le thread de la demande se bloque jusqu'à ce qu'il reçoive un message réponse de la part de tous les membres du cluster, l'informant que la mise à jour a été appliquée avec succès. L'utilisation de la réplication synchronisée garantit que les changements sont appliqués tout autour du cluster avant que la demande Web ne se termine. Cependant, le réplication synchronisée est bien!
  plus lente."
+msgstr "<emphasis role=\"bold\">CacheMode</emphasis> contrôle la manière dont le cache est reproduit. Les valeurs valides sont <literal>REPL_SYNC</literal> et <literal>REPL_ASYNC</literal>. Quel que soit le cas de figure, le thread de demande en provenance du client met à jour le cache local des contenus de sessions courantes, puis envoie un message vers les caches des autres membres du cluster, en les instruisant de procéder au même changement. Avec REPL_ASYNC (par défaut) le thread de demande retourne dès que le message mis à jour a été posté sur le réseau. Avec REPL_SYNC, le thread de la demande se bloque jusqu'à ce qu'il reçoive un message réponse de la part de tous les membres du cluster, l'informant que la mise à jour a été appliquée avec succès. L'utilisation de la réplication synchronisée garantit que les changements sont appliqués tout autour du cluster avant que la demande Web ne se termine. Cependant, le réplication synchronisée est bien !
 plus lente."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1221
@@ -4635,7 +4635,7 @@
 "<emphasis role=\"bold\">LockAcquisitionTimeout</emphasis> sets the maximum "
 "number of milliseconds to wait for a lock acquisition when trying to lock a "
 "cache node. The default value is 15000."
-msgstr "<emphasis role=\"bold\">LockAcquisitionTimeout</emphasis> détermine le nombre maximum de millesecondes qu'il faut attendre pour acquérir un verrouillage quand on essaie de verrouiller un noeud cache. La valeur par défaut est de 15 000."
+msgstr "<emphasis role=\"bold\">LockAcquisitionTimeout</emphasis> détermine le nombre maximum de millesecondes qui doivent s'écouler pour acquérir un verrouillage quand on essaie de verrouiller un noeud cache. La valeur par défaut est de 15 000."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1238
@@ -4645,7 +4645,7 @@
 "of milliseconds to wait for a response from all nodes in the cluster when a "
 "synchronous replication message is sent out. The default value is 20000; "
 "should be a few seconds longer than LockAcquisitionTimeout."
-msgstr "<emphasis role=\"bold\">SyncReplTimeout</emphasis> détermine le nombre maximum de millesecondes qu'il faut attendre avant d'obtenir une réponse de la part de tous les noeuds du cluster quand on envoie un message de réplication synchronisé. La valeur par défaut est de 20 000; et devrait correspondre à quelques secondes supplémentaires par rapport à LockAcquisitionTimeout."
+msgstr "<emphasis role=\"bold\">SyncReplTimeout</emphasis> détermine le nombre maximum de millesecondes qui doivent s'écouler avant d'obtenir une réponse de la part de tous les noeuds du cluster quand on envoie un message de réplication synchronisé. La valeur par défaut est de 20 000; et devrait correspondre à quelques secondes supplémentaires par rapport à LockAcquisitionTimeout."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1246
@@ -4761,7 +4761,7 @@
 "SET_AND_GET is that it can have significant performance implications, since "
 "even reading immutable objects from the session (e.g., strings, numbers) "
 "will mark the read attributes as needing to be replicated."
-msgstr "<emphasis role=\"bold\">SET_AND_GET</emphasis>: avec cette police, tout attribut GET ou SET sera considéré comme souillé. Si un objet est retiré d'une session, et modifié sans avoir été réinscrit dans la session, le changement de cet objet sera répliqué. Le mauvais côté de SET_AND_GET, c'est qu'il peut y avoir d'importantes implicationa au niveau de la performance, car même la lecture d'objets immutables de la session (comme par exemple strings, nombres) va marquer les attributs read (lecture) 'à répliquer'."
+msgstr "<emphasis role=\"bold\">SET_AND_GET</emphasis>: avec cette police, tout attribut GET ou SET sera considéré comme souillé. Si un objet est retiré d'une session, et modifié sans avoir été réinscrit dans la session, le changement de cet objet sera répliqué. Le mauvais côté de SET_AND_GET, c'est qu'il peut y avoir d'importantes implications au niveau de la performance, car même la lecture d'objets immutables de la session (comme par exemple strings, nombres) va marquer les attributs read (lecture) 'à répliquer'."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1263
@@ -4777,7 +4777,7 @@
 "object is mutable, so it assumes it is an marks the attribute as dirty. This "
 "setting avoids the downside of SET while reducing the performance impact of "
 "SET_AND_GET. It is the default setting."
-msgstr "<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: cette police ressemble à la politique SET_AND_GET, sauf que les opérations GET qui retournent des valeurs d'attributs de types primitifs, ne marquent pas l'attribut en tant que souillés (dirty). Les types de systèmes Primitifs (String, Interger, Long, etc.) sont immutables, donc il n'y a pas de raison de marquer un attribut d'un type 'souillé' uniquement parce qu'il a été lu. Si une opération GET retourne une valeur de type non primitif, le gestionnaire de session ne possède pas de moyen facile de savoir si un objet est mutable, donc il assume qu'il l'est et marque l'attribut en tant que 'souillé'. Cette configuration permet d'éviter le mauvais coté de SET tout en réduisant l'impact de la performance de SET_AND_GET. C'est la configuration par défaut."
+msgstr "<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: cette police ressemble à la politique SET_AND_GET, sauf que les opérations GET qui retournent des valeurs d'attributs de types primitifs, ne marquent pas l'attribut en tant que souillé (dirty). Les types de systèmes Primitifs (String, Interger, Long, etc.) sont immutables, donc il n'y a pas de raison de marquer un attribut d'un type 'souillé' uniquement parce qu'il a été lu. Si une opération GET retourne une valeur de type non primitif, le gestionnaire de session ne possède pas de moyen simple de savoir si un objet est mutable, donc il assume qu'il l'est et marque l'attribut en tant que 'souillé'. Cette configuration permet d'éviter le mauvais coté de SET tout en réduisant l'impact de la performance de SET_AND_GET. C'est la configuration par défaut."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1266
@@ -4798,7 +4798,7 @@
 "without being replicated, as a safeguard its timestamp will be replicated no "
 "matter what. So, ACCESS is only useful in special circumstances where the "
 "above safeguard is considered inadequate."
-msgstr "<emphasis role=\"bold\">ACCESS</emphasis>: cette option amène la session à être marquée comme 'souillée' à chaque fois qu'on y accède. Comme une session est accédée pour chaque demande HTTP, elle sera repliquée à chaque demande. Le but d'ACCESS est d'assurer que les références temporelles de dernier accès soient bien synchronisées à travers le cluster. Comme avec les autres options de déclenchement-de-réplication, la référence temporelle n'est peut-être pas mise à jour dans d'autres noeuds du cluster, car par manque de réplication, la session d'autres noeuds risque d'expirer avant le noeud actif, si la demande HTTP ne retire pas ou ne modifie pas d'attributs de session. Quand l'option est déterminée, les références temporelles qui s'appliquent à la session, seront synchronisées à travers les noeuds du cluster. Notez que l'utilisation de cette option peut avoir un impact de performance significatif, donc l'utiliser avec soin. Avec les au!
 tres options de déclenchement de réplication, si une session a duré 80% de son interval d'expiration sans avoir été répliquée, sa référence temporelle sera répliquée de toute façon, par précaution. Donc, ACCESS est seulement utile en cas de circonstances spéciales, quand cette précaution est considérée inadéquate."
+msgstr "<emphasis role=\"bold\">ACCESS</emphasis>: cette option amène la session à être marquée comme 'souillée' à chaque fois qu'on y accède. Comme une session est accédée pour chaque demande HTTP, elle sera repliquée à chaque demande. Le but d'ACCESS est d'assurer que les références temporelles de dernier accès soient bien synchronisées à travers le cluster. Comme avec les autres options de déclenchement de réplication, la référence temporelle ne sera peut-être pas mise à jour dans d'autres noeuds du cluster, car par manque de réplication, la session d'autres noeuds risque d'expirer avant le noeud actif si la demande HTTP ne retire pas ou ne modifie pas d'attributs de session. Quand l'option est déterminée, les références temporelles qui s'appliquent à la session, seront synchronisées à travers les noeuds du cluster. Notez que l'utilisation de cette option peut avoir un impact de performance significatif, donc l'utiliser avec précaution. Ave!
 c les autres options de déclenchement de réplication, si une session a duré 80% de son interval d'expiration sans avoir été répliquée, sa référence temporelle sera répliquée de toute façon, par précaution. Donc, ACCESS est seulement utile en cas de circonstances spéciales, quand cette précaution est considérée inadéquate."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1269
@@ -4824,7 +4824,7 @@
 "attributes are separately deserialized on the remote nodes, each Person "
 "object will now have a reference to its own Address object; the Address "
 "object will no longer be shared."
-msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: la réplication s'applique uniquement aux attributs 'souillés' de la session, et à des données de session, comme la référence temporelle de dernier accès. Pour les sessions qui comportent de grands volumes de données, cette option peut augmenter la performance de réplication. Cependant, les attributs seront sérialisés séparément, de façon à ce que s'il existe des références partagées entre les objets stockés dans les attributs, ces références partagées pourraient être interrompues sur les noeuds distants. Ainsi, prenons un objet Person, stocké sous la clé \"husband\" et qui a une référence vers l'objet Address, tandis qu'un autre objet Person, stocké sous la clé \"wife\" a une référence vers ce même objet Address. Quand les attributs \"husband\" et \"wife\" sont désérialisés séparément sur les noeuds distants, chaque objet Person possédera maintenant une référence à son propre obje!
 t Address, et l'objet Address ne sera donc plus partagé."
+msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: la réplication s'applique uniquement aux attributs 'souillés' de la session, et à des données de session, comme la référence temporelle de dernier accès. Pour les sessions qui comportent de grands volumes de données, cette option peut augmenter la performance de réplication. Cependant, les attributs seront sérialisés séparément, de façon à ce que, s'il existe des références partagées entre les objets stockés dans les attributs, ces références partagées pourraient être interrompues sur les noeuds distants. Ainsi, prenons un objet Person, stocké sous la clé \"husband\" et qui a une référence vers l'objet Address, tandis qu'un autre objet Person, stocké sous la clé \"wife\" a une référence vers ce même objet Address. Quand les attributs \"husband\" et \"wife\" sont désérialisés séparément sur les noeuds distants, chaque objet Person possédera maintenant une référence à son propre obj!
 et Address, et l'objet Address ne sera donc plus partagé."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1277
@@ -4845,7 +4845,7 @@
 "references will be preserved across the cluster. Potentially most "
 "performant, but requires changes to your application (this will be discussed "
 "later)."
-msgstr "<emphasis role=\"bold\">FIELD</emphasis>: la réplication est uniquement pour les champs de données modifiés par les individus, qui se trouvent à l'intérieur des objets d'attributs de session. Les références d'objets partagés seront préservés à travers le groupement. Potentiellement plus performants, mais nécessite des changements au niveau de votre application (dont on discutera plus tard)."
+msgstr "<emphasis role=\"bold\">FIELD</emphasis>: la réplication est uniquement pour les champs de données modifiés par les individus, qui se trouvent à l'intérieur des objets d'attributs de session. Les références d'objets partagés seront préservés à travers le groupement. C'est potentiellement plus performant, mais requiert des changements au niveau de votre application (dont on discutera plus tard)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1285
@@ -4885,7 +4885,7 @@
 "whole cluster. To use FIELD-level replication, you have to first prepare (i."
 "e., bytecode enhance) your Java class to allow the session cache to detect "
 "when fields in cached objects have been changed and need to be replicated."
-msgstr "La réplication niveau FIELD (champ) ne réplique que les champs de données modifiées, au sein des objets stockés dans la session. Son utilisation pourrait potentiellement réduire dramatiquement le volume de données qui circule entre les noeuds clusterisés, et améliorer ainsi la performance de tout le cluster. Pour utiliser la réplication niveau-FIELD, vous devrez tout d'abord préparer (c'est à dire souligner le code à octets) votre classe Java pour permettre au cache de la session de détecter quand les champs ont été modifiés ou ont besoin d'être répliqués dans les objets cachés."
+msgstr "La réplication niveau FIELD (champ) ne réplique que les champs de données modifiées, au sein des objets stockés dans la session. Son utilisation pourrait potentiellement réduire dramatiquement le volume de données qui circulent entre les noeuds clusterisés, et améliorer ainsi la performance de tout le cluster. Pour utiliser la réplication niveau-FIELD, vous devrez tout d'abord préparer (c'est à dire souligner le code à octets) votre classe Java pour permettre au cache de la session de détecter quand les champs ont été modifiés ou quand ils ont besoin d'être répliqués dans les objets cachés."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1301
@@ -5103,7 +5103,7 @@
 "data classes. Notice that there is no need to call <literal>session."
 "setAttribute()</literal> after you make changes to the data object, and all "
 "changes to the fields are automatically replicated across the cluster."
-msgstr "Finalement, voyons un exemple sur la façon d'utiliser la réplication niveau-FIELD sur ces classes de données. Notez qu'il n'y a pas besoin d'appeler <literal>session.setAttribute()</literal> après que vos ayez fait des changements à l'objet de données, et tous les changements appliqués au champs sont automatiquement répliqués à travers le cluster."
+msgstr "Finalement, voyons un exemple sur la façon d'utiliser la réplication niveau-FIELD sur ces classes de données. Notez qu'il n'y a pas besoin d'appeler <literal>session.setAttribute()</literal> après que vos ayiez fait des changements à l'objet de données, et tous les changements appliqués au champs sont automatiquement répliqués à travers le cluster."
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1357
@@ -5339,7 +5339,7 @@
 msgstr ""
 "La stratégie la plus simple et la plus utilisée communément pour déployer un Singleton HA est de prendre un déploiement ordinaire (war, ear, jar, ou ce que vous déploieriez normalement) et le déployer dans le répertoire <literal>HAPartition</literal> au lieu de <literal>deploy</"
 "literal>. Le répertoire <literal>deploy-hasingleton</literal> n'est pas sous Deploy ou Farm, donc son contenu n'est pas automatiquement déployé quand une instance AS démarre. Déployer le contenu de ce répertoire relève de la responsabilité d'un service spécial, le MBean <literal>jboss.ha:"
-"service=HASingletonDeployer</literal> (qui est lui-même déployé via le fichier deploy/deploy-hasingleton-service.xml). Le service HASingletonDeployer est lui-même un Singleton HA, dont la fonction est de déployer de contenu de deploy-hasingleton quand il devient Maître-noeud, et cesser le déploiement du contenu <literal>deploy-hasingleton</literal> quand il n'est plus le Maître-noeud (normalement au moment de la fermeture du serveur)."
+"service=HASingletonDeployer</literal> (qui est lui-même déployé via le fichier deploy/deploy-hasingleton-service.xml). Le service HASingletonDeployer est lui-même un Singleton HA, dont la fonction est de déployer de contenu de deploy-hasingleton quand il devient Maître-noeud, et de cesser le déploiement du contenu <literal>deploy-hasingleton</literal> quand il n'est plus le Maître-noeud (normalement au moment de la fermeture du serveur)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1408
@@ -5350,7 +5350,7 @@
 "the master node cleanly shuts down, they will be cleanly undeployed as part "
 "of shutdown. If the master node fails or is shut down, they will be deployed "
 "on whatever node takes over as master."
-msgstr "Ainsi, en mettant vos déploiements dans <literal>deploy-hasingleton</literal>, vous savez qu'ils ne seront déployés que sur le Maître-noeud au sein du groupement. Si le Maître-noeud ferme proprement, ils seront déployés proprement, dans le cadre du processus de fermeture. Si le Maître-noeud est défaillant ou est fermé, ils seront déployés sur n'importe quel noeud prenant la relève en tant que Maître-noeud."
+msgstr "Ainsi, en mettant vos déploiements dans <literal>deploy-hasingleton</literal>, vous savez qu'ils ne seront déployés que sur le Maître-noeud au sein du groupement. Si le Maître-noeud ferme correctement, ils seront bien déployés, dans le cadre du processus de fermeture. Si le Maître-noeud est défaillant ou est fermé, ils seront déployés sur n'importe quel noeud prenant la relève en tant que Maître-noeud."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1411
@@ -5379,7 +5379,7 @@
 "it will be providing services. Depending on how complex the deployment of "
 "your service is and what sorts of startup activities it engages in, this "
 "could take a while, during which time the service is not being provided."
-msgstr "Si le Maître-noeud est défaillant et qu'un autre noeud prend son rôle à sa place, vos services Singleton ont besoin de passer à nouveau par le processus total de déploiement avant d'être en mesure de procurer des services. Suivant le niveau de complexité du déploiement de votre service, et le genre d'activités au démarrage, cela peut prendre un certain temps, au cours duquel le service n'est pas opérationnel."
+msgstr "Si le Maître-noeud est défaillant et qu'un autre noeud prenne son rôle à sa place, vos services Singleton auront besoin de passer à nouveau par le processus total de déploiement avant d'être en mesure de procurer des services. Suivant le niveau de complexité du déploiement de votre service, et le genre d'activités au démarrage, cela peut prendre un certain temps, au cours duquel le service n'est pas opérationnel."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1432
@@ -5410,7 +5410,7 @@
 "only thing special about it is it needs to expose in its MBean interface a "
 "method that can be called when it should begin providing service, and "
 "another that can be called when it should stop providing service:"
-msgstr "Tout d'abord, nous avons une service Mbean que nous voulons transformer en HA Singleton. Ce qu\"il a de spécial, c'est qu'il a besoin d'exposer, dans son interface MBean, une méthode qui pourra être appelée quand il aura besoin de commencer à procurer un service, et une autre méthode, quand il devra cesser de le procurer :"
+msgstr "Tout d'abord, nous avons un service Mbean que nous voulons transformer en HA Singleton. Ce qu\"il a de spécial, c'est qu'il a besoin d'exposer, dans son interface MBean, une méthode qui pourra être appelée quand il aura besoin de commencer à procurer un service, et une autre méthode, quand il devra cesser de le procurer :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1439
@@ -5537,7 +5537,7 @@
 #: Clustering_Guide_Introduction.xml:1449
 #, no-c-format
 msgid "Voila! A clustered singleton service."
-msgstr "Voila un service Singleton clusterisé!"
+msgstr "Voilà un service Singleton clusterisé!"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1451
@@ -5554,7 +5554,7 @@
 "implement startSingleton() at which point it can immediately provide service."
 msgstr ""
 "Le seul problème avec cette approche, c'est que ça ne fonctionne qu'avec MBeans. D'un autre côté, l'exemple ci-dessus peut être placé dans <literal>deploy</literal> ou "
-"<literal>farm</literal>, et peut donc être 'déployé-à -chaud' ou 'farmed'. Aussi, si notre service mis en exemple, contient des exigences complexes et longues de démarrage, elles peuvent être implémentées par les méthodes create() ou start() dès que le service est déployé. Il n'a pas besoin d'attendre que le noeud devienne un maître-noeud. Ainsi, le service pourrait prêt à partir, juste le temps pour le contrôleur d'implémenter startSingleton(), pour finalement pouvoir procurer le service."
+"<literal>farm</literal>, et peut donc être 'déployé-à -chaud' ou 'farmed'. Aussi, si notre service pris en exemple, contient des exigences complexes et longues de démarrage, elles peuvent être implémentées par les méthodes create() ou start() dès que le service est déployé. Il n'a pas besoin d'attendre que le noeud devienne un maître-noeud. Ainsi, le service pourrait prêt à partir, juste le temps pour le contrôleur d'implémenter startSingleton(), pour finalement pouvoir procurer le service."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1454
@@ -5628,7 +5628,7 @@
 "singleton service's start/stop methods can take an argument, in this case "
 "the location of the directory the <literal>MainDeployer</literal> should "
 "deploy/undeploy."
-msgstr "Quelques points intéressants ici. Tout d'abord, le service contrôlé est le service <literal>MainDeployer</literal>, qui est le service de déploiement principal de JBoss. C'est un service qui n'a pas été écrit avec l'intention d'être contrôlé par un <literal>HASingletonController</literal>. Mais il fonctionne toujours! Deuxièmement, les méthodes cible 'start' et 'stop' sont 'deploy' (déployer) et 'undeploy'(rétracter un déploiement). Il n'ont pas besoin de posséder des noms particuliers, ou même d'avoir logiquement la fonctionnalité 'start' ou 'stop'. Ici, la fonctionnalité des méthodes invoquées est plutôt comme 'do' ou 'undo'. Finalement, prenez note des attributs “<literal>TargetStart(Stop)MethodArgument</literal>”. Vos méthodes start/stop de service Singleton peuvent prendre un argument, et dans ce cas, l'argument correspond à la location que le répertoire <literal>MainDeployer</literal> devrait déployer/rétracter."
+msgstr "Quelques points intéressants ici. Tout d'abord, le service contrôlé est le service <literal>MainDeployer</literal>, qui est le service de déploiement principal de JBoss. C'est un service qui n'a pas été écrit avec l'intention d'être contrôlé par un <literal>HASingletonController</literal>. Mais il fonctionne toujours! Deuxièmement, les méthodes cible 'start' et 'stop' sont 'deploy' (déployer) et 'undeploy'(rétracter un déploiement). Il n'ont pas besoin de posséder de noms particuliers, ou même d'avoir logiquement la fonctionnalité 'start' ou 'stop'. Ici, la fonctionnalité des méthodes invoquées est plutôt comme 'do' ou 'undo'. Finalement, prenez note des attributs “<literal>TargetStart(Stop)MethodArgument</literal>”. Vos méthodes start/stop de service Singleton peuvent prendre un argument, et dans ce cas, l'argument correspond à la location que le répertoire <literal>MainDeployer</literal> devrait déployer/rétracter."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1467
@@ -5681,7 +5681,7 @@
 "This provides an alternative to the deploy-hasingleton approach in that we "
 "can use farming to distribute the service, while content in deploy-"
 "hasingleton must be copied manually on all nodes."
-msgstr "Cela présente une approche alternative par rapport à l'approche deploy-hasingleton, dans la mesure où on peut utiliser 'farming' pour distribuer le service, alors que le contenu de deploy-hasingleton doit être copié manuellement sur chaque noeud."
+msgstr "Cela présente une approche alternative par rapport à l'approche deploy-hasingleton, dans la mesure où l'on peut utiliser 'farming' pour distribuer le service, alors que le contenu de deploy-hasingleton doit être copié manuellement sur chaque noeud."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1479
@@ -5714,7 +5714,7 @@
 "normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
 "literal>) will not have the desired effect."
 msgstr ""
-"Barrier contrôle start/stop des services dépendants, mais pas leur destruction, qui n'a lieu que lorsque <literal>BarrierController</literal> est lui-même détruit/non déployé. Ainsi, utiliser <literal>Barrier</"
+"Barrier contrôle le start/stop des services dépendants, mais pas leur destruction, qui n'a lieu que lorsque <literal>BarrierController</literal> est lui-même détruit/non déployé. Ainsi, utiliser <literal>Barrier</"
 "literal> pour contrôler les services qui ont besoin d'être 'détruits' dans le cadre de leur opération 'undeploy' (rétraction du déploiement) habituelle (comme, par exemple, un <literal>EJBContainer</"
 "literal>) n'aura pas l'effet désiré."
 
@@ -5816,7 +5816,7 @@
 "the <literal>all</literal> server configuration. In the current production "
 "release of JBoss AS, the HA-JMS service is implemented as a clustered "
 "singleton fail-over service."
-msgstr "JBoss AS 3.2.4 et versions supérieures supportent les services hautement disponibles JMS (HA-JMS) dans la configuration de serveur <literal>all</literal>. Dans le version actuelle de production de JBoss AS, le service HA-JMS est implémenté en tant que service fail-over singleton clusterisé."
+msgstr "JBoss AS 3.2.4 et versions supérieures supportent les services hautement disponibles JMS (HA-JMS) dans la configuration de serveur <literal>all</literal>. Dans la version actuelle de production de JBoss AS, le service HA-JMS est implémenté en tant que service fail-over singleton clusterisé."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1541
@@ -5837,7 +5837,7 @@
 "JBoss Messaging project. JBoss Messaging's clustering implementation is "
 "considerably different from HA-JMS based on JBoss MQ; most notably it is not "
 "based on a singleton service only running on one node in the cluster."
-msgstr "produit."
+msgstr "HA-JMS in JBoss AS 4.2.2 et versions inférieures, étaient basés sur le produit de messagerie JBoss MQ. Dans les dernières versions de sortie de AS, JBoss MQ a été remplacé par le dernier projet JBoss Messaging. L'implémentation de clusterisation de JBoss Messaging est très différente de celle de HA-JMS basé sur JBoss MQ, surtout ce n'est pas basé sur le service singleton qui n'est exécuté que sur un noeud du groupement."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1554
@@ -5856,7 +5856,7 @@
 "are deployed on that server (fail-over). This setup provides redundancy "
 "against server failures but does not reduce the work load on the JMS server "
 "node."
-msgstr "Le service JBoss HA-HMS (c'est à dire files d'attente de messages, topics et les services de prise en charge) ne sont uniquement exécutés que sur un noeud simple (comme le Maître-noeud) du cluster, à tout moment. Si ce noeud échoue, le cluster choisit un autre noeud pour exécuter le service JMS, et les files d'attente, topics et autres services déployés sur ce server (fail-over). Cette installation fournit de la redondance contre les défaillances de serveurs, mais de réduit pas la charge de travail pour autant sur le noeud de serveur JMS."
+msgstr "Le service JBoss HA-HMS (c'est à dire files d'attente de messages, topics et les services de prise en charge) n'est uniquement exécuté que sur un noeud simple (comme le Maître-noeud) du cluster, à tout moment. Si ce noeud échoue, le cluster choisit un autre noeud pour exécuter le service JMS, et les files d'attente, topics et autres services déployés sur ce server (fail-over). Cette installation fournit de la redondance contre les défaillances de serveurs, mais ne réduit pas la charge de travail pour autant sur le noeud de serveur JMS."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1557
@@ -5888,7 +5888,7 @@
 "running on one node in the cluster at a time."
 msgstr ""
 "La plus grande différence de configuration entre HA-JMS dans la configuration 'all' et la version non-HA qui se trouve dans la configuration par défaut, c'est la location de la plupart des fichiers de configuration. Pour HA-JMS, la plupart des fichiers de configuration se trouvent dans le répertoire deploy-hasingleton/jms, et non pas dans deploy/jms. Vos files d'attente et vos topics doivent être déployés dans deploy-hasingleton (ou dans un de ces sous-répertoires comme "
-"deploy-hasingleton/jms.) Les composants d'application qui agissent en tant que clients envers HA-JMS (c'est à dire, MDB et autres clients JMS) n'ont pas besoin de déployer dans deploy-hasingleton. Ils doivent uniquement être déployés à cet endroit si vous souhaitez qu'ils soient exécutés sur un seul noeud du cluster à la fois."
+"deploy-hasingleton/jms). Les composants d'application qui agissent en tant que clients envers HA-JMS (c'est à dire, MDB et autres clients JMS) n'ont pas besoin de déployer dans deploy-hasingleton. Ils doivent uniquement être déployés à cet endroit si vous souhaitez qu'ils soient exécutés sur un seul noeud du cluster à la fois."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1567
@@ -5899,7 +5899,7 @@
 "related service MBeans and all deployed queues and topics. However, "
 "applications that use JMS (e.g., MDBs and other JMS clients) do not need to "
 "be deployed identically across the cluster."
-msgstr "Pour utiliser le service de fail-over HA-JMS, vous devrez configurer les services JMS de façon identique sur tous les noeuds du cluster. Ceci inclut tous les MBeans de service relatifs JMS, tous les topics et files d'attentes déployées. Cependant, les applications qui utilisent JMS (comme MDB et autres clients JMS) n'ont pas besoin d'être déployés de façon identique à travers le cluster."
+msgstr "Pour utiliser le service de fail-over HA-JMS, vous devrez configurer les services JMS de façon identique sur tous les noeuds du cluster. Ceci inclut tous les MBeans de service relatifs JMS, tous les topics et files d'attentes déployées. Cependant, les applications qui utilisent JMS (comme MDB et autres clients JMS) n'ont pas besoin d'être déployées de façon identique à travers le cluster."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1573
@@ -5915,7 +5915,7 @@
 "setup a shared database for JMS. You need to do the following:"
 msgstr ""
 "Le serveur JMS est configuré de façon à pouvoir persister ses données dans <literal>DefaultDS</"
-"literal>. Par défaut, c'est HSQLDB intégré. Cependant, pour que le services HA-JMS fail-over fonctionne, le nouveau serveur HA-JMS doit être en mesure de trouver les données persistées par l'ancien serveur. Cela ne risque pas d'avoir lieu si les données sont persistées dans des fichiers écrits par le HSQLDB des anciens serveurs. Dans presque n'importe quel environnement de cluster, tous les noeuds doivent persister des données sur une base de données partagées. Donc, la première chose à faire, avant de démarrer JMS clusterisé, c'est d'installer la base de données partagées de JMS. Vous devrez procéder ainsi :"
+"literal>. Par défaut, c'est HSQLDB intégré. Cependant, pour que le services HA-JMS fail-over fonctionne, le nouveau serveur HA-JMS doit être en mesure de trouver les données persistées par l'ancien serveur. Cela ne risque pas d'avoir lieu si les données sont persistées dans des fichiers écrits par le HSQLDB des anciens serveurs. Dans presque n'importe quel environnement de cluster, tous les noeuds doivent persister des données sur une base de données partagée. Donc, la première chose à faire, avant de démarrer JMS clusterisé, c'est d'installer la base de données partagée de JMS. Vous devrez procéder ainsi :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1579
@@ -5927,7 +5927,7 @@
 "examples/jca</literal> directory, where <literal>xxx</literal> is the name "
 "of the target shared database (e.g., <literal>mysql-ds.xml</literal>)."
 msgstr ""
-"Configurer <literal>DefaultDS</literal> pour pointer vers le serveur de base de données de votre choix. C'est pour remplacer le fichier <literal>deploy/hsqlsb-ds.xml</literal> "
+"Configurez <literal>DefaultDS</literal> pour pointer vers le serveur de base de données de votre choix. C'est pour remplacer le fichier <literal>deploy/hsqlsb-ds.xml</literal> "
 "par le fichier <literal>xxx-ds.xml</literal> dans le répertoire <literal>docs/"
 "examples/jca</literal>, dans lequel <literal>xxx</literal> est le nom de la base de données partagée de la cible (par ex., <literal>mysql-ds.xml</literal>)."
 
@@ -5943,8 +5943,8 @@
 "<literal>docs/examples/jms</literal>."
 msgstr ""
 "Remplacer le fichier <literal>hsqldb-jdbc2-service.xml</literal> du répertoire"
-"<literal>server/all/deploy-hasingleton/jms</literal> par un fichier accordé à la base de donnée spécifique."
-"<literal>mysql-jdbc2-service.xml</literal>. Les fichiers de configuration d'un certain nombre de RDBMS sont groupés dans la distribution JBoss AS. Ils peuvent être trouvés dans <literal>docs/examples/jms</literal>."
+"<literal>server/all/deploy-hasingleton/jms</literal> par un fichier accordé à la base de données spécifique."
+"<literal>mysql-jdbc2-service.xml</literal>. Les fichiers de configuration d'un certain nombre de RDBMS sont groupés dans la distribution JBoss AS. Ils sont situés dans <literal>docs/examples/jms</literal>."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1595
@@ -5982,7 +5982,7 @@
 "and topicsusing HA-JNDI (the default port is 1100). This ensures the factory/"
 "queue/topic can be found no matter which cluster node is running the HA-JMS "
 "server."
-msgstr "Le client HA-JMS doit chercher dans les usines de connexion JMS, ainsi que dans les files d'attente et topics, en utilisant HA-JNDI (le port par défaut étant 1100). Cela garantit que l'usine/la file d'attente/le topic peut être trouvé, quel que soit le noeud de cluster qui exécute le serveur HA-JMS."
+msgstr "Le client HA-JMS doit chercher dans les usines de connexion JMS, ainsi que dans les files d'attente et topics, en utilisant HA-JNDI (le port par défaut étant 1100). Cela garantit que l'usine/la file d'attente/le topic peut être trouvé(e), quel que soit le noeud de cluster qui exécute le serveur HA-JMS."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1620
@@ -6097,7 +6097,7 @@
 "the task of closing the old connection and reconnecting. Following is a "
 "example application that continuously sends messages to a queue, handling "
 "any exceptions that occur:"
-msgstr "Pour les clients qui se trouvent en dehors du serveur d'application, la meilleure approche est d'enregistrer un ExceptionListener avec la connexion; le listener recevra un callback s'il y a une exception sur la connexion. Le callback devra alors gérer la tâche de fermer l'ancienne connexion et de reconnecter. Vous trouverez ci-dessous un exemple d'application qui envoie sans cesse des messages vers une file d'attente, en s'occupant de n'importe quelle exception qu'il rencontre :"
+msgstr "Pour les clients qui se trouvent en dehors du serveur d'application, la meilleure approche est d'enregistrer un ExceptionListener avec la connexion; le listener recevra un callback s'il y a une exception sur la connexion. Le callback devra alors gérer la tâche de fermer l'ancienne connexion et de reconnecter. Vous trouverez ci-dessous un exemple d'application qui envoie sans cesse des messages vers une file d'attente, en gérant n'importe quelle exception :"
 
 #. Tag: programlisting
 #: Clustering_Guide_Introduction.xml:1657
@@ -6513,7 +6513,7 @@
 "configured as MBeans. There is a set of JBossCache and JGroups MBeans for "
 "each type of clustering applications (e.g., the Stateful Session EJBs, HTTP "
 "session replication etc.)."
-msgstr "JGroups et JBoss Cache fournissent la communication sous-jacente, la réplication de noeuds et les services cache pour les groupements JBoss AS. Ces services sont configurés en tant que MBeans. Il existe un ensemble de MBeans JBossCache et JGrups pour chaque type d'applications de clustering (c'est à dire la session à état EJB, la réplication de session HTTP, etc.)."
+msgstr "JGroups et JBoss Cache fournissent la communication sous-jacente, la réplication de noeuds et les services cache pour les groupements JBoss AS. Ces services sont configurés en tant que MBeans. Il existe un ensemble de MBeans JBossCache et JGroups pour chaque type d'applications de clustering (c'est à dire la session à état EJB, la réplication de session HTTP, etc.)."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1709
@@ -6524,7 +6524,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 pofiner quand vous déployez une application liée à un réseau particulier ou qui est régie par des prérequis de performance particuliers."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1714
@@ -6730,7 +6730,7 @@
 "is what defines the characteristics of the overall Channel. In the next "
 "several sections, we will dig into the commonly used protocols and their "
 "options and explain exactly what they mean."
-msgstr "Toutes les données de configuration JGroups sont contenues dans l'élément &lt;Config&gt; sous l'attribut MBean de configuration JGroups. Cette information est utilisée pour configurer un canal JGroup. Le canal est conçu sur le modèle d'une connexion logicielle, et gère la communication entre les noeuds homologues au sein d'un cluster. Chaque élément qui se trouve dans l'élément &lt;Config&gt; définit un protocole JGroups particulier. Chaque protocole performe une seule fonction, et la combinaison de ces fonctions est ce qui définit les caractéristiques du canal dans son ensemble. Dans les sections qui suivent, nous allons nous pencher sur les protocoles les plus utilisés et les options qui y sont associées, et expliquer ce qu'ils signifient."
+msgstr "Toutes les données de configuration JGroups sont contenues dans l'élément &lt;Config&gt; sous l'attribut MBean de configuration JGroups. Cette information est utilisée pour configurer un canal JGroup. Le canal est conçu sur le modèle d'une connexion logicielle, et gère la communication entre les noeuds homologues au sein d'un cluster. Chaque élément qui se trouve dans l'élément &lt;Config&gt; définit un protocole JGroups particulier. Chaque protocole performe une seule fonction, et la combinaison de ces fonctions est ce qui définit les caractéristiques du canal dans son ensemble. Dans les sections qui suivent, nous allons nous pencher sur les protocoles les plus utilisés et les options qui y sont associées, et les expliquer."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1737
@@ -6744,7 +6744,7 @@
 msgid ""
 "The following common properties are exposed by all of the JGroups protocols "
 "discussed below:"
-msgstr "Les propriétés communes suivantes sont présentés par tous les protocoles JGroups exposés ci-dessous :"
+msgstr "Les propriétés communes suivantes sont présentées par tous les protocoles JGroups exposés ci-dessous :"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1742
@@ -6805,7 +6805,7 @@
 "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."
+"literal> sont exclusifs les uns des autres. Vous ne pouvez avoir qu'un seul protocole de transport pour chaque élément <literal>Config</literal> de JGroups."
 
 #. Tag: title
 #: Clustering_Guide_Introduction.xml:1766
@@ -6878,7 +6878,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 "<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."
+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 n packets unicast à la place de packets 1 multicast. Dans tous les cas, les paquets sont des datagrammes UDP."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1782
@@ -6910,7 +6910,7 @@
 "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."
+"bind_address</literal>, si elle est présente). Si vous avez une machine multihomed, configurez la propriété du système ou 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_Introduction.xml:1794
@@ -6956,7 +6956,7 @@
 "but is actually something of a misnomer, since the value here refers to how "
 "many network hops a packet will be allowed to travel before networking "
 "equipment will drop it."
-msgstr "<emphasis role=\"bold\">ip_ttl</emphasis> 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."
+msgstr "<emphasis role=\"bold\">ip_ttl</emphasis> précise la durée de vie (time-to-live) des packets Multicast IP. TTL est une terme communément utilisé en réseautage multicast, mais cette appellation est 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_Introduction.xml:1814
@@ -6968,7 +6968,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 "<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>."
+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_Introduction.xml:1817
@@ -6990,7 +6990,7 @@
 "elapsed, whichever occurs first. Then bundle queued messages into a large "
 "message and send it. The messages are unbundled at the receiver. The default "
 "is <literal>false</literal>."
-msgstr "<emphasis role=\"bold\">enable_bundling</emphasis> 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>."
+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 dégroupés au niveau de récepteur. La valeur par défaut est <literal>max_bundle_size</literal>."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1828
@@ -7000,7 +7000,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 "<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>"
+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. La valeur par défaut est <literal>false</literal>"
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1833
@@ -7024,7 +7024,7 @@
 "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."
+"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 tenue de la surcharge de mémoire tampon."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1845
@@ -7128,7 +7128,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 "<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."
+msgstr "<emphasis role=\"bold\">recv_buf_size, send_buf_size</emphasis> détermine les tailles des mémoires tampon pour recevoir et envoyer. Il est bon d'avoir une grande taille de mémoire tampon 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_Introduction.xml:1889
@@ -7159,7 +7159,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 "<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."
+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 continuez après le délai de timeout pour sonder les autres membres par ping."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1902
@@ -7168,7 +7168,7 @@
 "<emphasis role=\"bold\">use_send_queues</emphasis> specifies whether to use "
 "separate send queues for each connection. This prevents blocking on write if "
 "the peer hangs. The default is true."
-msgstr "<emphasis role=\"bold\">use_send_queues</emphasis> 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."
+msgstr "<emphasis role=\"bold\">use_send_queues</emphasis> précise si on doit ou non utiliser des files d'attente d'envoi séparé 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_Introduction.xml:1905
@@ -7208,7 +7208,7 @@
 "(by setting <literal>enable_bundling</literal> to false). Nagling is "
 "disabled by setting <literal>tcp_nodelay</literal> to true. The default is "
 "false."
-msgstr "<emphasis role=\"bold\">tcp_nodelay</emphasis> 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."
+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 sync, 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_Introduction.xml:1923
@@ -7296,7 +7296,7 @@
 "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-"
+"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 sachent 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
@@ -7327,7 +7327,7 @@
 "joiner determines the coordinator from the responses, and sends a JOIN "
 "request to it (handled by). If nobody responds, we assume we are the first "
 "member of a group."
-msgstr "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."
+msgstr "PNG est un protocole discovery qui fonctionne soit en diffusant multiples 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éterminera le coordinateur à partir des réponses, et lui enverra une requête JOINTE. Si personne ne répond pas, on assume que nous sommes les premiers membres d'un groupe."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:1969
@@ -7444,8 +7444,7 @@
 "multicasting for discovery."
 msgstr ""
 "Si les deux <literal>gossip_host</literal> et <literal>gossip_port</literal> "
-"sont définis, le cluster utilise le GossipRouter pour le discovery initial. Si le <literal>initial_hosts</literal> est spécifié, le cluster "
-"interroge par PING la liste statique d'adresses pour discovery. Dans les "
+"sont définis, le cluster utilise le GossipRouter pour le discovery initial. Si le <literal>initial_hosts</literal> est spécifié, le cluster interroge par PING la liste statique d'adresses pour discovery. Dans les "
 "autres cas, le cluster utilise le multicast IP pour discovery."
 
 #. Tag: para
@@ -7770,7 +7769,7 @@
 "suspected. The simplest FD_SOCK configuration does not take any attribute. "
 "You can just declare an empty <literal>FD_SOCK</literal> element in "
 "JGroups's <literal>Config</literal> element."
-msgstr "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>."
+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_Introduction.xml:2167
@@ -7884,7 +7883,7 @@
 #: Clustering_Guide_Introduction.xml:2228
 #, no-c-format
 msgid "High timeouts will not detect and remove crashed members for some time."
-msgstr "Les timeouts élevés ne détecteront pas, ni ne retirerons les membres plantés avant un bon moment."
+msgstr "Les timeouts élevés ne détecteront pas, ni ne retireront les membres plantés avant un bon moment."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2235
@@ -7948,7 +7947,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 "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."
+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 où 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 ce 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_Introduction.xml:2282
@@ -7960,7 +7959,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 "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 :"
+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 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_Introduction.xml:2287
@@ -8014,7 +8013,7 @@
 "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 "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."
+msgstr "L'assurance de protocoles de livraison fiables dans la pile JGroups, garantit que les poches de données soient livrées dans le bon ordre (FIFO) vers le noeud de destination. La preuve de livraison de messages 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 soit 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_Introduction.xml:2309
@@ -8125,7 +8124,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 "<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."
+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_Introduction.xml:2353
@@ -8143,7 +8142,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 "<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"
+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."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2364
@@ -8184,7 +8183,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 "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."
+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_Introduction.xml:2387
@@ -8227,7 +8226,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 "<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."
+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_Introduction.xml:2402
@@ -8351,7 +8350,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 "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."
+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 besoin 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
@@ -8367,7 +8366,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 "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."
+msgstr "Ce protocole fragmente des messages supérieurs à une certaine taille, et 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
@@ -8498,7 +8497,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 "<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."
+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 utilisé en conjonction avec max_bytes, cet attribut devrait être paramétré avec un nombre inférieur."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2526
@@ -8721,7 +8720,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 "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."
+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 aceesibles par 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 que les utilisateurs peuvent rencontrer avec le clustering JBoss."
 
 #. Tag: para
 #: Clustering_Guide_Introduction.xml:2623
@@ -8760,7 +8759,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 "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."
+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
@@ -8789,7 +8788,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 "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."
+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, il 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
@@ -8834,7 +8833,7 @@
 "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."
+"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
@@ -8889,7 +8888,7 @@
 "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 "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."
+msgstr "Si des canaux associés à des noms de groupe différents partagent le même 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, ou pourra entraîner un comportement anormal."
 
 #. Tag: emphasis
 #: Clustering_Guide_Introduction.xml:2673
@@ -8906,7 +8905,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 "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."
+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, quelle que 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
@@ -8929,8 +8928,8 @@
 "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> "
+"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. Allez dans le répertoire<literal>$JBOSS_HOME/server/all/lib</literal> "
 "et démarrez McastReceiverTest, par exemple :"
 
 #. Tag: screen

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Naming.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Naming.po	2009-03-31 06:03:42 UTC (rev 86511)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Naming.po	2009-03-31 06:17:26 UTC (rev 86512)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Naming\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-15 03:45+0000\n"
-"PO-Revision-Date: 2009-03-31 10:34+1000\n"
+"PO-Revision-Date: 2009-03-31 10:56+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -4320,9 +4320,8 @@
 "référence EJB n'est pas accessible à partir d'autres composants "
 "d'application à l'exécution et que les autres composants d'application "
 "peuvent définir les éléments <literal>ejb-ref</literal> avec le même "
-"<literal>ejb-ref-name</literal> sans causer de conflit de nommage. L' fournit un fragment de <literal>e<xref linkend=\"EJB_References-An_example_ejb_jar.xml_ejb_ref_descriptor_fragment\"/>jb-jar.xml</"
-"literal> qui illustre l'utilisation de l'élément <literal>ejb-ref</literal>. "
-"Un échantillon de code qui illustre l'accès à la référence "
+"<literal>ejb-ref-name</literal> sans causer de conflit de nommage. <xref linkend=\"EJB_References-An_example_ejb_jar.xml_ejb_ref_descriptor_fragment\"/> fournit un fragment <literal>ejb-jar.xml</"
+"literal> qui illustre l'élément <literal>ejb-ref</literal>. Un échantillon de code qui illustre l'accès à la référence "
 "<literal>ShoppingCartHome</literal> déclarée dans l'<xref linkend=\"EJB_References-An_example_ejb_jar.xml_ejb_ref_descriptor_fragment\"/> est donné dans l'<xref linkend=\"EJB_References-ENC_ejb_ref_access_code_fragment\"/>."
 
 #. Tag: title