[jboss-cvs] JBossAS SVN: r68091 - projects/docs/trunk/Server_Configuration_Guide/es-ES.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Dec 10 01:07:28 EST 2007
Author: xhuang at jboss.com
Date: 2007-12-10 01:07:25 -0500 (Mon, 10 Dec 2007)
New Revision: 68091
Added:
projects/docs/trunk/Server_Configuration_Guide/es-ES/Alternative_DBs.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Author_Group.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_EJBs.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Entity_EJBs.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_HTTP.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Intro.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JMS.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JNDI.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Deploy.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/EJB3.po
projects/docs/trunk/Server_Configuration_Guide/es-ES/Legal_Notice.po
Modified:
projects/docs/trunk/Server_Configuration_Guide/es-ES/Transactions.po
Log:
Merge with latest en-US
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Alternative_DBs.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Alternative_DBs.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Alternative_DBs.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,822 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Alternative_DBs.xml:2
+#, no-c-format
+msgid "Use Alternative Databases with JBoss AS"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:4
+#, no-c-format
+msgid "How to Use Alternative Databases"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:5
+#, no-c-format
+msgid ""
+"JBoss utilizes the Hypersonic database as its default database. While this "
+"is good for development and prototyping, you or your company will probably "
+"require another database to be used for production. This chapter covers "
+"configuring JBoss AS to use alternative databases. We cover the procedures "
+"for all officially supported databases on the JBoss Application Server. They "
+"include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, "
+"Sybase ASE 12.5, as well as MS SQL 2005."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:8
+#, no-c-format
+msgid ""
+"Please note that in this chapter, we explain how to use alternative "
+"databases to support all services in JBoss AS. This includes all the system "
+"level services such as EJB and JMS. For individual applications (e.g., WAR "
+"or EAR) deployed in JBoss AS, you can still use any backend database by "
+"setting up the appropriate data source connection as described in <xref "
+"linkend=\"Connectors_on_JBoss-Configuring_JDBC_DataSources\"/>."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:10
+#, no-c-format
+msgid ""
+"We assume that you have already installed the external database server, and "
+"have it running. You should create an empty database named <literal>jboss</"
+"literal>, accessible via the username / password pair <literal>jbossuser / "
+"jbosspass</literal>. The <literal>jboss</literal> database is used to store "
+"JBoss AS internal data -- JBoss AS will automatically create tables and data "
+"in it."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:15
+#, no-c-format
+msgid "Install JDBC Drivers"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:17
+#, no-c-format
+msgid ""
+"For the JBoss Application Server and our applications to use the external "
+"database, we also need to install the database's JDBC driver. The JDBC "
+"driver is a JAR file, which you'll need to copy into your JBoss AS's "
+"<literal>jboss-as/server/production/lib</literal> directory. Replace "
+"<literal>production</literal> with the server configuration you are using if "
+"needed. This file is loaded when JBoss starts up. So if you have the JBoss "
+"AS running, you'll need to shut down and restart. The availability of JDBC "
+"drivers for different databases are as follows."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:22
+#, no-c-format
+msgid ""
+"IBM DB2 JDBC drivers can be downloaded from the IBM web site <ulink url="
+"\"http://www-306.ibm.com/software/data/db2/java/\">http://www-306.ibm.com/"
+"software/data/db2/java/</ulink>."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:25
+#, no-c-format
+msgid ""
+"Sybase JDBC drivers can be downloaded from the Sybase jConnect product page "
+"<ulink url=\"http://www.sybase.com/products/allproductsa-z/"
+"softwaredeveloperkit/jconnect\">http://www.sybase.com/products/allproductsa-"
+"z/softwaredeveloperkit/jconnect</ulink>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:27
+#, no-c-format
+msgid ""
+"MS SQL Server JDBC drivers can be downloaded from the MSDN web site <ulink "
+"url=\"http://msdn.microsoft.com/data/jdbc/\">http://msdn.microsoft.com/data/"
+"jdbc/</ulink>."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:30
+#, no-c-format
+msgid "Special notes on Sybase"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:31
+#, no-c-format
+msgid ""
+"Some of the services in JBoss uses null values for the default tables that "
+"are created. Sybase Adaptive Server should be configured to allow nulls by "
+"default. <screen><command>sp_dboption db_name, \"allow nulls by default\", "
+"true</command></screen> Refer the sybase manuals for more options."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:39
+#, no-c-format
+msgid "Enable JAVA services"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:40
+#, no-c-format
+msgid ""
+"To use any java service like JMS, CMP, timers etc. configured with Sybase, "
+"java should be enabled on Sybase Adaptive Server. To do this use: "
+"<screen><command>sp_configure \"enable java\",1</command></screen> Refer to "
+"the sybase manuals for more information."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:47
+#, no-c-format
+msgid ""
+"If java is not enabled you might see this exception being thrown when you "
+"try to use any of the above services."
+msgstr ""
+
+#. Tag: screen
+#: Alternative_DBs.xml:49
+#, no-c-format
+msgid ""
+"com.sybase.jdbc2.jdbc.SybSQLException: Cannot run this command because Java "
+"services are not enabled. A user with System Administrator (SA) role must "
+"reconfigure the system to enable Java"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:53
+#, no-c-format
+msgid "CMP Configuration"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:54
+#, no-c-format
+msgid ""
+"To use Container Managed Persistence for user defined Java objects with "
+"Sybase Adaptive Server Enterprise the java classes should be installed in "
+"the database. The system table 'sysxtypes' contains one row for each "
+"extended, Java-SQL datatype. This table is only used for Adaptive Servers "
+"enabled for Java. Install java classes using the installjava program. "
+"<screen><command>installjava -f <jar-file-name> -S<sybase-"
+"server> -U<super-user> -P<super-pass> -D<db-name></"
+"command></screen> Refer the installjava manual in Sybase for more options."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:64
+#, no-c-format
+msgid "Installing Java Classes"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:68
+#, no-c-format
+msgid ""
+"You have to be a super-user with required privileges to install java classes."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:73
+#, no-c-format
+msgid ""
+"The jar file you are trying to install should be created without compression."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:78
+#, no-c-format
+msgid ""
+"Java classes that you install and use in the server must be compiled with "
+"JDK 1.2.2. If you compile a class with a later JDK, you will be able to "
+"install it in the server using the installjava utility, but you will get a "
+"java.lang.ClassFormatError exception when you attempt to use the class. This "
+"is because Sybase Adaptive Server uses an older JVM internally, and hence "
+"requires the java classes to be compiled with the same."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:90
+#, no-c-format
+msgid "Creating a DataSource for the External Database"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:92
+#, no-c-format
+msgid ""
+"JBoss AS connects to relational databases via datasources. These datasource "
+"definitions can be found in the <literal>jboss-as/server/production/deploy</"
+"literal> directory. The datasource definitions are deployable just like WAR "
+"and EAR files. The datasource files can be recognized by looking for the XML "
+"files that end in <literal>*-ds.xml</literal>."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:94
+#, no-c-format
+msgid ""
+"The datasource definition files for all supported external databases can be "
+"found in the <literal>jboss-as/docs/examples/jca</literal> directory."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:97
+#, no-c-format
+msgid "MySQL: <literal>mysql-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:98
+#, no-c-format
+msgid "PostgreSQL: <literal>postgres-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:99
+#, no-c-format
+msgid "Oracle: <literal>oracle-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:100
+#, no-c-format
+msgid "DB2: <literal>db2-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:101
+#, no-c-format
+msgid "Sybase: <literal>sybase-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:102
+#, no-c-format
+msgid "MS SQL Server: <literal>mssql-ds.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:105
+#, no-c-format
+msgid ""
+"The following code snippet shows the <literal>mysql-ds.xml</literal> file as "
+"an example. All the other <literal>*-ds.xml</literal> files are very "
+"similiar. You will need to change the <literal>connection-url</literal>, as "
+"well as the <literal>user-name</literal> / <literal>password</literal>, to "
+"fit your own database server installation."
+msgstr ""
+
+#. Tag: programlisting
+#: Alternative_DBs.xml:107
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<datasources>\n"
+" <local-tx-datasource>\n"
+" <jndi-name>MySqlDS</jndi-name>\n"
+" <connection-url>jdbc:mysql://localhost:3306/jboss</connection-url>\n"
+" <driver-class>com.mysql.jdbc.Driver</driver-class>\n"
+" <user-name>jbossuser</user-name>\n"
+" <password>jbosspass</password>\n"
+" <exception-sorter-class-name>\n"
+" org.jboss.resource.adapter.jdbc.vendor."
+"MySQLExceptionSorter\n"
+" </exception-sorter-class-name>\n"
+" <!-- should only be used on drivers after 3.22.1 with \"ping\" support\n"
+" <valid-connection-checker-class-name>\n"
+" org.jboss.resource.adapter.jdbc.vendor."
+"MySQLValidConnectionChecker\n"
+" </valid-connection-checker-class-name>\n"
+" -->\n"
+" <!-- sql to call when connection is created\n"
+" <new-connection-sql>some arbitrary sql</new-connection-sql>\n"
+" -->\n"
+" <!-- sql to call on an existing pooled connection when it is obtained "
+"from pool - \n"
+" MySQLValidConnectionChecker is preferred for newer drivers\n"
+" <check-valid-connection-sql>some arbitrary sql</check-valid-connection-"
+"sql>\n"
+" -->\n"
+"\n"
+" <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml "
+"(optional) -->\n"
+" <metadata>\n"
+" <type-mapping>mySQL</type-mapping>\n"
+" </metadata>\n"
+" </local-tx-datasource>\n"
+"\n"
+"</datasources>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:109
+#, no-c-format
+msgid ""
+"Once you customized the <literal>*-ds.xml</literal> file to connect to your "
+"external database, you need to copy it to the <literal>jboss-as/server/"
+"production/deploy</literal> directory. The database connection is now "
+"available through the JNDI name specified in the <literal>*-ds.xml</literal> "
+"file."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:114
+#, no-c-format
+msgid "Change Database for the JMS Services"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:116
+#, no-c-format
+msgid ""
+"The JMS service in the JBoss AS uses relational databases to persist its "
+"messages. For improved performance, we should change the JMS service to take "
+"advantage of the external database. To do that, we need to replace the file "
+"<literal>jboss-as/server/production/deploy/jms-singleton/hsqldb-jdbc2-"
+"service.xml</literal> with a file in <literal>jboss-as/docs/examples/jms/</"
+"literal> depending on your external database. Notice that if you are using "
+"the <literal>default</literal> server profile, the file path is "
+"<literal>jboss-as/server/default/deploy/jms/hsqldb-jdbc2-service.xml</"
+"literal>."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:119
+#, no-c-format
+msgid "MySQL: <literal>mysql-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:120
+#, no-c-format
+msgid "PostgreSQL: <literal>postgres-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:121
+#, no-c-format
+msgid "Oracle: <literal>oracle-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:122
+#, no-c-format
+msgid "DB2: <literal>db2-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:123
+#, no-c-format
+msgid "Sybase: <literal>sybase-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:124
+#, no-c-format
+msgid "MS SQL Server: <literal>mssql-jdbc2-service.xml</literal>"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:128
+#, no-c-format
+msgid "What about the hsqldb-jdbc-state-service.xml file?"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:129
+#, no-c-format
+msgid ""
+"Despite its name, the <literal>hsqldb-jdbc-state-service.xml</literal> file "
+"applies to all databases. So, there is no need to use a special "
+"<literal>jdbc-state-service.xml</literal> for each database."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:135
+#, no-c-format
+msgid "Support Foreign Keys in CMP Services"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:137
+#, no-c-format
+msgid ""
+"Next, we need to go change the <literal>jboss-as/server/production/conf/"
+"standardjbosscmp-jdbc.xml</literal> file so that the <literal>fk-constraint</"
+"literal> property is <literal>true</literal>. That is needed for all "
+"external databases we support on the JBoss Application Server. This file "
+"configures the database connection settings for the EJB2 CMP beans deployed "
+"in the JBoss AS."
+msgstr ""
+
+#. Tag: programlisting
+#: Alternative_DBs.xml:139
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<fk-constraint>true</fk-constraint>\n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:144
+#, no-c-format
+msgid "Specify Database Dialect for Java Persistence API"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:146
+#, no-c-format
+msgid ""
+"The Java Persistence API (JPA) entity manager can save EJB3 entity beans to "
+"any backend database. Hibernate provides the JPA implementation in JBoss AS. "
+"Hibernate has a dialect auto-detection mechanism that works for most "
+"databases including the dialects for databases referenced in this appendix "
+"which are listed below. If a specific dialect is needed for alternative "
+"databases, you can configure the database dialect in the <varname>jboss-as/"
+"server/production/deploy/ejb3.deployer/META-INF/persistence.properties</"
+"varname> file. You need to un-comment the <varname>hibernate.dialect</"
+"varname> property and change its value to the following based on the "
+"database you setup. For a complete list of dialects, refer to the Hibernate "
+"Reference Guide, Chapter 3, Section 4.1 SQL Dialects."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:149
+#, no-c-format
+msgid "Oracle 9i: org.hibernate.dialect.Oracle9iDialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:150
+#, no-c-format
+msgid "Oracle 10g: org.hibernate.dialect.Oracle10gDialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:151
+#, no-c-format
+msgid "Microsoft SQL Server 2005: org.hibernate.dialect.SQLServerDialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:152
+#, no-c-format
+msgid "PostgresSQL 8.1: org.hibernate.dialect.PostgreSQLDialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:153
+#, no-c-format
+msgid "MySQL 5.0: org.hibernate.dialect.MySQL5Dialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:154
+#, no-c-format
+msgid "DB2 8.0: org.hibernate.dialect.DB2Dialect"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:155
+#, no-c-format
+msgid "Sybase ASE 12.5: org.hibernate.dialect.SybaseDialect"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:158
+#, no-c-format
+msgid "DB2 7.2 with Universal JDBC Driver (Type 4)"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:159
+#, no-c-format
+msgid ""
+"Large Objects (LOBs) are supported only with DB2 Version 8 servers and above "
+"with the universal JDBC driver. Hence JMS services which stores messages as "
+"BLOBS and Timer services which uses BLOB fields for storing objects do not "
+"work with the JDBC Type 4 driver and DB2 7.2."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:165
+#, no-c-format
+msgid "DB2 7.2 with JDBC Type 2 driver"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:166
+#, no-c-format
+msgid ""
+"All JBoss services work with the JDBC Type 2 driver and DB2 Version 7.2 "
+"servers."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:176
+#, no-c-format
+msgid "Change Other JBoss AS Services to Use the External Database"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:178
+#, no-c-format
+msgid ""
+"Besides JMS, CMP, and JPA, we still need to hook up the rest of JBoss "
+"services with the external database. There are two ways to do it. One is "
+"easy but inflexible. The other is flexible but requires more steps. Now, "
+"let's discuss those two approaches respectively."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:181
+#, no-c-format
+msgid "The Easy Way"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:183 Alternative_DBs.xml:196
+#, no-c-format
+msgid ""
+"The easy way is just to change the JNDI name for the external database to "
+"<literal>DefaultDS</literal>. Most JBoss services are hard-wired to use the "
+"<literal>DefaultDS</literal> by default. So, by changing the datasource "
+"name, we do not need to change the configuration for each service "
+"individually."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:186
+#, no-c-format
+msgid ""
+"To change the JNDI name, just open the <literal>*-ds.xml</literal> file for "
+"your external database, and change the value of the <literal>jndi-name</"
+"literal> property to <literal>DefaultDS</literal>. For instance, in "
+"<literal>mysql-ds.xml</literal>, you'd change MySqlDS to DefaultDS and so "
+"on. You will need to remove the <literal>jboss-as/server/production/deploy/"
+"hsqldb-ds.xml</literal> file after you are done to avoid duplicated "
+"<literal>DefaultDS</literal> definition."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:189 Alternative_DBs.xml:200
+#, no-c-format
+msgid ""
+"In the <literal>jms/*-jdbc2-service.xml</literal> file, you should also "
+"change the datasource name in the <literal>depends</literal> tag for the "
+"<literal>PersistenceManagers</literal> MBean to <literal>DefaultDS</"
+"literal>. For instance, for <literal>mysql-jdbc2-service.xml</literal> file, "
+"we change the <literal>MySqlDS</literal> to <literal>DefaultDS</literal>."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:198
+#, no-c-format
+msgid ""
+"To change the JNDI name, just open the <literal>*-ds.xml</literal> file for "
+"your external database, and change the value of the <literal>jndi-name</"
+"literal> property to <literal>DefaultDS</literal>. For instance, in "
+"<literal>mysql-ds.xml</literal>, you'd change <literal>MySqlDS</literal> to "
+"<literal>DefaultDS</literal> and so on. You will need to remove the "
+"<literal>jboss-as/server/production/deploy/hsqldb-ds.xml</literal> file "
+"after you are done to avoid duplicated <literal>DefaultDS</literal> "
+"definition."
+msgstr ""
+
+#. Tag: programlisting
+#: Alternative_DBs.xml:202
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"... ...\n"
+"<mbean code=\"org.jboss.mq.pm.jdbc2.PersistenceManager\"\n"
+" name=\"jboss.mq:service=PersistenceManager\">\n"
+" <depends optional-attribute-name=\"ConnectionManager\">\n"
+" jboss.jca:service=DataSourceBinding,name=DefaultDS\n"
+" </depends>\n"
+" ... ...\n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:207
+#, no-c-format
+msgid "The More Flexible Way"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:209
+#, no-c-format
+msgid ""
+"Changing the external datasource to <literal>DefaultDS</literal> is "
+"convenient. But if you have applications that assume the <literal>DefaultDS</"
+"literal> always points to the factory-default HSQL DB, that approach could "
+"break your application. Also, changing <literal>DefaultDS</literal> "
+"destination forces all JBoss services to use the external database. What if "
+"you want to use the external database only on some services?"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:211
+#, no-c-format
+msgid ""
+"A safer and more flexible way to hook up JBoss AS services with the external "
+"datasource is to manually change the <literal>DefaultDS</literal> in all "
+"standard JBoss services to the datasource JNDI name defined in your "
+"<literal>*-ds.xml</literal> file (e.g., the <literal>MySqlDS</literal> in "
+"<literal>mysql-ds.xml</literal> etc.). Below is a complete list of files "
+"that contain <literal>DefaultDS</literal>. You can update them all to use "
+"the external database on all JBoss services or update some of them to use "
+"different combination of datasources for different services."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:214
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/conf/login-config.xml</literal>: This "
+"file is used in Java EE container managed security services."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:216
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/conf/standardjbosscmp-jdbc.xml</"
+"literal>: This file configures the CMP beans in the EJB container."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:218
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/ejb-deployer.xml</literal>: This "
+"file configures the JBoss EJB deployer."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:220
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/schedule-manager-service.xml</"
+"literal>: This file configures the EJB timer services."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:222
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/snmp-adaptor.sar/attributes.xml</"
+"literal>: This file is used by the SNMP service."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:224
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/juddi-service.sar/META-INF/jboss-"
+"service.xml</literal>: This file configures the UUDI service."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:226
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/juddi-service.sar/juddi.war/WEB-"
+"INF/jboss-web.xml</literal>: This file configures the UUDI service."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:228
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/juddi-service.sar/juddi.war/WEB-"
+"INF/juddi.properties</literal>: This file configures the UUDI service."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:230
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/deploy/uuid-key-generator.sar/META-INF/"
+"jboss-service.xml</literal>: This file configures the UUDI service."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:232
+#, no-c-format
+msgid ""
+"<literal>jboss-as/server/production/jms/hsqldb-jdbc-state-service.xml</"
+"literal> and <literal>jboss-as/server/all/deploy-hasingleton/jms/hsqldb-jdbc-"
+"state-service.xml</literal>: Those files configure the JMS persistence "
+"service as we discussed earlier."
+msgstr ""
+
+#. Tag: title
+#: Alternative_DBs.xml:241
+#, no-c-format
+msgid "A Special Note About Oracle DataBases"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:243
+#, no-c-format
+msgid ""
+"In our setup discussed in this chapter, we rely on the JBoss AS to "
+"automatically create needed tables in the external database upon server "
+"startup. That works most of the time. But for databases like Oracle, there "
+"might be some minor issues if you try to use the same database server to "
+"back more than one JBoss AS instance."
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:245
+#, no-c-format
+msgid ""
+"The Oracle database creates tables of the form <literal>schemaname."
+"tablename</literal>. The <literal>TIMERS</literal> and "
+"<literal>HILOSEQUENCES</literal> tables needed by JBoss AS would not get "
+"created on a schema if the table already exists on a different schema. To "
+"work around this issue, you need to edit the <literal>jboss-as/server/"
+"production/deploy/ejb-deployer.xml</literal> file to change the table name "
+"from <literal>TIMERS</literal> to something like <literal>schemaname2."
+"tablename</literal>."
+msgstr ""
+
+#. Tag: programlisting
+#: Alternative_DBs.xml:247
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"... ...\n"
+" <mbean code=\"org.jboss.ejb.txtimer.DatabasePersistencePolicy\" \n"
+" name=\"jboss.ejb:service=EJBTimerService,persistencePolicy=database"
+"\">\n"
+" <!-- DataSourceBinding ObjectName -->\n"
+" <depends optional-attribute-name=\"DataSource\">\n"
+" jboss.jca:service=DataSourceBinding,name=DefaultDS\n"
+" </depends>\n"
+" <!-- The plugin that handles database persistence -->\n"
+" <attribute name=\"DatabasePersistencePlugin\">\n"
+" org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin\n"
+" </attribute>\n"
+" <!-- The timers table name -->\n"
+" <attribute name=\"TimersTable\">TIMERS</attribute>\n"
+" </mbean> \n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: Alternative_DBs.xml:249
+#, no-c-format
+msgid ""
+"Similarly, you need to change the <literal>jboss-as/server/production/deploy/"
+"uuid-key-generator.sar/META-INF/jboss-service.xml</literal> file to change "
+"the table name from <literal>HILOSEQUENCES</literal> to something like "
+"<literal>schemaname2.tablename</literal> as well."
+msgstr ""
+
+#. Tag: programlisting
+#: Alternative_DBs.xml:251
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"... ...\n"
+" <!-- HiLoKeyGeneratorFactory -->\n"
+" <mbean code=\"org.jboss.ejb.plugins.keygenerator.hilo."
+"HiLoKeyGeneratorFactory\"\n"
+" name=\"jboss:service=KeyGeneratorFactory,type=HiLo\">\n"
+" \n"
+" <depends>jboss:service=TransactionManager</depends>\n"
+"\n"
+" <!-- Attributes common to HiLo factory instances -->\n"
+" \n"
+" <!-- DataSource JNDI name -->\n"
+" <depends optional-attribute-name=\"DataSource\">jboss.jca:"
+"service=DataSourceBinding,name=DefaultDS</depends>\n"
+"\n"
+" <!-- table name -->\n"
+" <attribute name=\"TableName\">HILOSEQUENCES</attribute>\n"
+" \n"
+" ... ...\n"
+"]]>"
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Author_Group.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Author_Group.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Author_Group.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,164 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: author
+#: Author_Group.xml:6
+#, no-c-format
+msgid "<firstname>Alessio</firstname> <surname>Soldano</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:16
+#, no-c-format
+msgid "<firstname>Andreadis</firstname> <surname>Dimitris</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:25
+#, no-c-format
+msgid "<firstname>Bill</firstname> <surname>Burke</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:35
+#, no-c-format
+msgid "<firstname>Brian</firstname> <surname>Stansberry</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:45
+#, no-c-format
+msgid "<firstname>Carlo</firstname> <surname>de Wolf</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:55
+#, no-c-format
+msgid "<firstname>Galder</firstname> <surname>Zamarreno</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:65
+#, no-c-format
+msgid "<firstname>Heiko</firstname> <surname>Braun</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:75
+#, no-c-format
+msgid "<firstname>Michael</firstname> <surname>Yuan</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:85
+#, no-c-format
+msgid "<firstname>Roger</firstname> <surname>Pearse</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:95
+#, no-c-format
+msgid "<firstname>Shelly</firstname> <surname>Mc Gowan</surname>"
+msgstr ""
+
+#. Tag: author
+#: Author_Group.xml:105
+#, no-c-format
+msgid "<firstname>Thomas</firstname> <surname>Diesler</surname>"
+msgstr ""
+
+#. Tag: editor
+#: Author_Group.xml:116
+#, no-c-format
+msgid "<firstname>Samson</firstname> <surname>Kittoli</surname>"
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:132
+#, no-c-format
+msgid "<firstname>Myriam</firstname> <surname>Malga</surname>"
+msgstr ""
+
+#. Tag: contrib
+#: Author_Group.xml:135 Author_Group.xml:142
+#, no-c-format
+msgid "Translation of this book to French."
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:139
+#, no-c-format
+msgid "<firstname>Fabian</firstname> <surname>Decroux</surname>"
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:147
+#, no-c-format
+msgid "<firstname>Jasna</firstname> <surname>Dimanoski</surname>"
+msgstr ""
+
+#. Tag: contrib
+#: Author_Group.xml:151
+#, no-c-format
+msgid "Translation of this book to German."
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:157
+#, no-c-format
+msgid "<firstname>Yoko</firstname> <surname>Nanamiya</surname>"
+msgstr ""
+
+#. Tag: contrib
+#: Author_Group.xml:160 Author_Group.xml:168 Author_Group.xml:175
+#, no-c-format
+msgid "Translation of this book to Japanese."
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:164
+#, no-c-format
+msgid "<firstname>James</firstname> <surname>Hashida</surname>"
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:172
+#, no-c-format
+msgid "<firstname>Noriko</firstname> <surname>Mizumoto</surname>"
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:179
+#, no-c-format
+msgid "<firstname>Glaucia</firstname> <surname>Freitas</surname>"
+msgstr ""
+
+#. Tag: contrib
+#: Author_Group.xml:182
+#, no-c-format
+msgid "Translation of this book to Portuguese."
+msgstr ""
+
+#. Tag: othercredit
+#: Author_Group.xml:187
+#, no-c-format
+msgid "<firstname>Angela</firstname> <surname>Garcia</surname>"
+msgstr ""
+
+#. Tag: contrib
+#: Author_Group.xml:190
+#, no-c-format
+msgid "Translation of this book to Spanish."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_EJBs.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_EJBs.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_EJBs.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,892 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:5
+#, no-c-format
+msgid "Clustered Session EJBs"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:6
+#, no-c-format
+msgid ""
+"Session EJBs provide remote invocation services. They are clustered based on "
+"the client-side interceptor architecture. The client application for a "
+"clustered session bean is exactly the same as the client for the non-"
+"clustered version of the session bean, except for a minor change to the "
+"<literal>java.naming.provier.url</literal> system property to enable HA-JNDI "
+"lookup (see previous section). No code change or re-compilation is needed on "
+"the client side. Now, let's check out how to configure clustered session "
+"beans in EJB 2.x and EJB 3.0 server applications respectively."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:13
+#, no-c-format
+msgid "Stateless Session Bean in EJB 2.x"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:14
+#, no-c-format
+msgid ""
+"Clustering stateless session beans is most probably the easiest case: as no "
+"state is involved, calls can be load-balanced on any participating node (i."
+"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><clustered></literal> tag."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:18
+#, no-c-format
+msgid ""
+"<jboss> \n"
+" <enterprise-beans> \n"
+" <session> \n"
+" <ejb-name>nextgen.StatelessSession</ejb-"
+"name> \n"
+" <jndi-name>nextgen.StatelessSession</jndi-"
+"name> \n"
+" <clustered>True</clustered> \n"
+" <cluster-config> \n"
+" <partition-name>DefaultPartition</partition-"
+"name> \n"
+" <home-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces.RoundRobin \n"
+" </home-load-balance-policy> \n"
+" <bean-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces.RoundRobin\n"
+" </bean-load-balance-policy>\n"
+" </cluster-config>\n"
+" </session>\n"
+" </enterprise-beans>\n"
+"</jboss>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:21
+#, no-c-format
+msgid ""
+"The <literal><clustered>True</clustered></literal> element is "
+"really just an alias for the <literal><configuration-name>Clustered "
+"Stateless SessionBean</configuration-name></literal> element in the "
+"conf/standard-jboss.xml file."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:26
+#, no-c-format
+msgid ""
+"In the bean configuration, only the <clustered> element is mandatory. "
+"It indicates that the bean needs to support clustering features. The <"
+"cluster-config> element is optional and the default values of its "
+"attributes are indicated in the sample configuration above. Below is a "
+"description of the attributes in the <cluster-config> element.."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:29
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">partition-name</emphasis> specifies the name of the "
+"cluster the bean participates in. The default value is "
+"<literal>DefaultPartition</literal>. The default partition name can also be "
+"set system-wide using the <literal>jboss.partition.name</literal> system "
+"property."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:35
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">home-load-balance-policy</emphasis> indicates the "
+"class to be used by the home stub to balance calls made on the nodes of the "
+"cluster. By default, the proxy will load-balance calls in a "
+"<literal>RoundRobin</literal> fashion. You can also implement your own load-"
+"balance policy class or use the class <literal>FirstAvailable</literal> that "
+"persists to use the first node available that it meets until it fails."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:42
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bean-load-balance-policy</emphasis> Indicates the "
+"class to be used by the bean stub to balance calls made on the nodes of the "
+"cluster. Comments made for the <literal>home-load-balance-policy</literal> "
+"attribute also apply."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:51
+#, no-c-format
+msgid "Stateful Session Bean in EJB 2.x"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:52
+#, no-c-format
+msgid ""
+"Clustering stateful session beans is more complex than clustering their "
+"stateless counterparts since JBoss needs to manage the state information. "
+"The state of all stateful session beans are replicated and synchronized "
+"across the cluster each time the state of a bean changes. The JBoss AS uses "
+"the <literal>HASessionState</literal> MBean to manage distributed session "
+"states for clustered EJB 2.x stateful session beans. In this section, we "
+"cover both the session bean configuration and the <literal>HASessionState</"
+"literal> MBean configuration."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:59
+#, no-c-format
+msgid "The EJB application configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:60
+#, no-c-format
+msgid ""
+"In the EJB application, you need to modify the <literal>jboss.xml</literal> "
+"descriptor file for each stateful session bean and add the <literal><"
+"clustered></literal> tag."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:62
+#, no-c-format
+msgid ""
+"<jboss> \n"
+" <enterprise-beans>\n"
+" <session> \n"
+" <ejb-name>nextgen.StatefulSession</ejb-"
+"name> \n"
+" <jndi-name>nextgen.StatefulSession</jndi-"
+"name> \n"
+" <clustered>True</clustered> \n"
+" <cluster-config> \n"
+" <partition-name>DefaultPartition</partition-"
+"name>\n"
+" <home-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces.RoundRobin \n"
+" </home-load-balance-policy> \n"
+" <bean-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces."
+"FirstAvailable \n"
+" </bean-load-balance-policy> \n"
+" <session-state-manager-jndi-name> \n"
+" /HASessionState/Default \n"
+" </session-state-manager-jndi-name> \n"
+" </cluster-config> \n"
+" </session> \n"
+" </enterprise-beans>\n"
+"</jboss>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:63
+#, no-c-format
+msgid ""
+"In the bean configuration, only the <literal><clustered></literal> tag "
+"is mandatory to indicate that the bean works in a cluster. The <literal><"
+"cluster-config></literal> element is optional and its default attribute "
+"values are indicated in the sample configuration above."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:67
+#, no-c-format
+msgid ""
+"The <literal><session-state-manager-jndi-name></literal> tag is used "
+"to give the JNDI name of the <literal>HASessionState</literal> service to be "
+"used by this bean."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:69
+#, no-c-format
+msgid ""
+"The description of the remaining tags is identical to the one for stateless "
+"session bean. Actions on the clustered stateful session bean's home "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:75
+#, no-c-format
+msgid "Optimize state replication"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:76
+#, no-c-format
+msgid ""
+"As the replication process is a costly operation, you can optimise this "
+"behaviour by optionally implementing in your bean class a method with the "
+"following signature:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:78
+#, no-c-format
+msgid "public boolean isModified ();"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:79
+#, no-c-format
+msgid ""
+"Before replicating your bean, the container will detect if your bean "
+"implements this method. If your bean does, the container calls the "
+"<literal>isModified()</literal> method and it only replicates the bean when "
+"the method returns <literal>true</literal>. If the bean has not been "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:87
+#, no-c-format
+msgid "The HASessionState service configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:88
+#, no-c-format
+msgid ""
+"The <literal>HASessionState</literal> service MBean is defined in the "
+"<code>all/deploy/cluster-service.xml</code> file."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:90
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<mbean code=\"org.jboss.ha.hasessionstate.server.HASessionStateService\"\n"
+" name=\"jboss:service=HASessionState\">\n"
+" \n"
+" <depends>jboss:service=Naming</depends> \n"
+" <!-- We now inject the partition into the HAJNDI service instead \n"
+" of requiring that the partition name be passed --> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" \n"
+" proxy-type=\"attribute\">\n"
+" jboss:service=${jboss.partition.name:DefaultPartition}\n"
+" </depends>\n"
+" <!-- JNDI name under which the service is bound -->\n"
+" <attribute name=\"JndiName\">/HASessionState/Default</attribute>\n"
+" <!-- Max delay before cleaning unreclaimed state.\n"
+"Defaults to 30*60*1000 => 30 minutes -->\n"
+"<attribute name=\"BeanCleaningDelay\">0</attribute>\n"
+"</mbean> ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:92
+#, no-c-format
+msgid ""
+"The configuration attributes in the <literal>HASessionState</literal> MBean "
+"are listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:95
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ClusterPartition</emphasis> is a required attribute "
+"to inject the HAPartition service that HA-JNDI uses for intra-cluster "
+"communication."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:100
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">JndiName</emphasis> is an optional attribute to "
+"specify the JNDI name under which this <literal>HASessionState</literal> "
+"service is bound. The default value is <literal>/HAPartition/Default</"
+"literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:106
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">BeanCleaningDelay</emphasis> is an optional "
+"attribute to specify the number of miliseconds after which the "
+"<literal>HASessionState</literal> service can clean a state that has not "
+"been modified. If a node, owning a bean, crashes, its brother node will take "
+"ownership of this bean. Nevertheless, the container cache of the brother "
+"node will not know about it (because it has never seen it before) and will "
+"never delete according to the cleaning settings of the bean. That is why the "
+"<literal>HASessionState</literal> service needs to do this cleanup "
+"sometimes. The default value is <literal>30*60*1000</literal> milliseconds "
+"(i.e., 30 minutes)."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:117
+#, no-c-format
+msgid "Handling Cluster Restart"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:118
+#, no-c-format
+msgid ""
+"We have covered the HA smart client architecture in the section called "
+"“Client-side interceptor architecture”. The default HA smart proxy client "
+"can only failover as long as one node in the cluster exists. If there is a "
+"complete cluster shutdown, the proxy becomes orphaned and loses knowledge of "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:121
+#, no-c-format
+msgid ""
+"The 3.2.7+/4.0.2+ releases contain a RetryInterceptor that can be added to "
+"the proxy client side interceptor stack to allow for a transparent recovery "
+"from such a restart failure. To enable it for an EJB, setup an invoker-proxy-"
+"binding that includes the RetryInterceptor. Below is an example jboss.xml "
+"configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:124
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+" <jboss>\n"
+" <session>\n"
+" <ejb-name>nextgen_RetryInterceptorStatelessSession</ejb-name>\n"
+" <invoker-bindings>\n"
+" <invoker>\n"
+" <invoker-proxy-binding-name>\n"
+" clustered-retry-stateless-rmi-invoker\n"
+" </invoker-proxy-binding-name>\n"
+" <jndi-name>\n"
+" nextgen_RetryInterceptorStatelessSession\n"
+" </jndi-name>\n"
+" </invoker>\n"
+" </invoker-bindings>\n"
+" <clustered>true</clustered>\n"
+" </session>\n"
+" \n"
+" <invoker-proxy-binding>\n"
+" <name>clustered-retry-stateless-rmi-invoker</name>\n"
+" <invoker-mbean>jboss:service=invoker,type=jrmpha</invoker-mbean>\n"
+" <proxy-factory>org.jboss.proxy.ejb.ProxyFactoryHA</proxy-factory>\n"
+" <proxy-factory-config>\n"
+" <client-interceptors>\n"
+" <home>\n"
+" <interceptor>\n"
+" org.jboss.proxy.ejb.HomeInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.SecurityInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.TransactionInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.ejb.RetryInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.invocation.InvokerInterceptor\n"
+" </interceptor>\n"
+" </home>\n"
+" <bean>\n"
+" <interceptor>\n"
+" org.jboss.proxy.ejb.StatelessSessionInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.SecurityInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.TransactionInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.proxy.ejb.RetryInterceptor\n"
+" </interceptor>\n"
+" <interceptor>\n"
+" org.jboss.invocation.InvokerInterceptor\n"
+" </interceptor>\n"
+" </bean>\n"
+" </client-interceptors>\n"
+" </proxy-factory-config>\n"
+" </invoker-proxy-binding> ]]>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:128
+#, no-c-format
+msgid "JNDI Lookup Process"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:129
+#, no-c-format
+msgid ""
+"In order to recover the HA proxy, the RetryInterceptor does a lookup in "
+"JNDI. This means that internally it creates a new InitialContext and does a "
+"JNDI lookup. But, for that lookup to succeed, the InitialContext needs to be "
+"configured properly to find your naming server. The RetryInterceptor will go "
+"through the following steps in attempting to determine the proper naming "
+"environment properties:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:133
+#, no-c-format
+msgid ""
+"It will check its own static retryEnv field. This field can be set by client "
+"code via a call to RetryInterceptor.setRetryEnv(Properties). This approach "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:138
+#, no-c-format
+msgid ""
+"If the retryEnv field is null, it will check for any environment properties "
+"bound to a ThreadLocal by the org.jboss.naming.NamingContextFactory class. "
+"To use this class as your naming context factory, in your jndi.properties "
+"set property java.naming.factory.initial=org.jboss.naming."
+"NamingContextFactory. The advantage of this approach is use of org.jboss."
+"naming.NamingContextFactory is simply a configuration option in your jndi."
+"properties file, and thus your java code is unaffected. The downside is the "
+"naming properties are stored in a ThreadLocal and thus are only visible to "
+"the thread that originally created an InitialContext."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:143
+#, no-c-format
+msgid ""
+"If neither of the above approaches yield a set of naming environment "
+"properties, a default InitialContext is used. If the attempt to contact a "
+"naming server is unsuccessful, by default the InitialContext will attempt to "
+"fall back on multicast discovery to find an HA-JNDI naming server. See the "
+"section on “ClusteredJNDI Services” for more on multicast discovery of HA-"
+"JNDI."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:152
+#, no-c-format
+msgid "SingleRetryInterceptor"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:153
+#, no-c-format
+msgid ""
+"The RetryInterceptor is useful in many use cases, but a disadvantage it has "
+"is that it will continue attempting to re-lookup the HA proxy in JNDI until "
+"it succeeds. If for some reason it cannot succeed, this process could go on "
+"forever, and thus the EJB call that triggered the RetryInterceptor will "
+"never return. For many client applications, this possibility is "
+"unacceptable. As a result, JBoss doesn't make the RetryInterceptor part of "
+"its default client interceptor stacks for clustered EJBs."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:156
+#, no-c-format
+msgid ""
+"In the 4.0.4.RC1 release, a new flavor of retry interceptor was introduced, "
+"the org.jboss.proxy.ejb.SingleRetryInterceptor. This version works like the "
+"RetryInterceptor, but only makes a single attempt to re-lookup the HA proxy "
+"in JNDI. If this attempt fails, the EJB call will fail just as if no retry "
+"interceptor was used. Beginning with 4.0.4.CR2, the SingleRetryInterceptor "
+"is part of the default client interceptor stacks for clustered EJBs."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:159
+#, no-c-format
+msgid ""
+"The downside of the SingleRetryInterceptor is that if the retry attempt is "
+"made during a portion of a cluster restart where no servers are available, "
+"the retry will fail and no further attempts will be made."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:169
+#, no-c-format
+msgid "Stateless Session Bean in EJB 3.0"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:170
+#, no-c-format
+msgid ""
+"To cluster a stateless session bean in EJB 3.0, all you need to do is to "
+"annotate the bean class withe the <literal>@Clustered</literal> annotation. "
+"You can pass in the load balance policy and cluster partition as parameters "
+"to the annotation. The default load balance policy is <literal>org.jboss.ha."
+"framework.interfaces.RandomRobin</literal> and the default cluster is "
+"<literal>DefaultPartition</literal>. Below is the definition of the "
+"<literal>@Cluster</literal> annotation."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:176
+#, no-c-format
+msgid ""
+"public @interface Clustered {\n"
+" Class loadBalancePolicy() default LoadBalancePolicy.class;\n"
+" String partition() default \"${jboss.partition.name:DefaultPartition}"
+"\";\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:177
+#, no-c-format
+msgid ""
+"Here is an example of a clustered EJB 3.0 stateless session bean "
+"implementation."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:178
+#, no-c-format
+msgid ""
+"@Stateless\n"
+"@Clustered\n"
+"public class MyBean implements MySessionInt {\n"
+" \n"
+" public void test() {\n"
+" // Do something cool\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:179
+#, no-c-format
+msgid ""
+"The <literal>@Clustered</literal> annotation can also be omitted and the "
+"clustering configuration applied in jboss.xml:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:182
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<jboss> \n"
+" <enterprise-beans>\n"
+" <session>\n"
+" <ejb-name>NonAnnotationStateful</ejb-name>\n"
+" <clustered>true</clustered>\n"
+" <cluster-config>\n"
+" <partition-name>FooPartition</partition-name>\n"
+" <load-balance-policy>\n"
+" org.jboss.ha.framework.interfaces.RandomRobin\n"
+" </load-balance-policy>\n"
+" </cluster-config>\n"
+" </session> \n"
+" </enterprise-beans>\n"
+"</jboss> ]]>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_EJBs.xml:187
+#, no-c-format
+msgid "Stateful Session Beans in EJB 3.0"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:188
+#, no-c-format
+msgid ""
+"To cluster stateful session beans in EJB 3.0, you need to tag the bean "
+"implementation class with the <literal>@Cluster</literal> annotation, just "
+"as we did with the EJB 3.0 stateless session bean earlier. The @org.jboss."
+"ejb3.annotation.cache.tree.CacheConfig annotation can also be applied to the "
+"bean to specify caching behavior. Below is the definition of the "
+"@CacheConfig annotation:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:193
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"public @interface CacheConfig\n"
+"{\n"
+"String name() default \"jboss.cache:service=EJB3SFSBClusteredCache\";\n"
+"int maxSize() default 10000;\n"
+"long idleTimeoutSeconds() default 300; \n"
+"boolean replicationIsPassivation() default true; \n"
+"long removalTimeoutSeconds() default 0;\n"
+"} ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:196
+#, no-c-format
+msgid ""
+"<literal>name</literal> specifies the object name of the JBoss Cache Mbean "
+"that should be used for caching the bean (see below for more on this Mbean)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:198
+#, no-c-format
+msgid ""
+"<literal>maxSize</literal> specifies the maximum number of beans that can "
+"cached before the cache should start passivating beans, using an LRU "
+"algorithm."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:200
+#, no-c-format
+msgid ""
+"<literal>idleTimeoutSeconds</literal> specifies the max period of time a "
+"bean can go unused before the cache should passivate it (irregardless of "
+"whether maxSize beans are cached.)"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:202
+#, no-c-format
+msgid ""
+"<literal>removalTimeoutSeconds</literal> specifies the max period of time a "
+"bean can go unused before the cache should remove it altogether."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:204
+#, no-c-format
+msgid ""
+"<literal>replicationIsPassivation</literal> specifies whether the cache "
+"should consider a replication as being equivalent to a passivation, and "
+"invoke any @PrePassivate and @PostActivate callbacks on the bean. By default "
+"true, since replication involves serializing the bean, and preparing for and "
+"recovering from serialization is a common reason for implementing the "
+"callback methods."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:209
+#, no-c-format
+msgid ""
+"Here is an example of a clustered EJB 3.0 stateful session bean "
+"implementation."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:216
+#, no-c-format
+msgid ""
+"@Stateful\n"
+"@Clustered\n"
+"@CacheConfig(maxSize=5000,removalTimeoutSeconds=18000)\n"
+"public class MyBean implements MySessionInt {\n"
+" \n"
+" private int state = 0;\n"
+"\n"
+" public void increment() {\n"
+" System.out.println(\"counter: \" + (state++));\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:218
+#, no-c-format
+msgid ""
+"As with stateless beans, the @Clustered annotation can also be omitted and "
+"the clustering configuration applied in jboss.xml; see the example above."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:221
+#, no-c-format
+msgid ""
+"As with EJB 2.0 clustered SFSBs, JBoss provides a mechanism whereby a bean "
+"implementation can expose a method the container can invoke to check whether "
+"the bean's state is not dirty after a request and doesn't need to be "
+"replicated. With EJB3, the mechanism is a little more formal; instead of "
+"just exposing a method with a known signature, an EJB3 SFSB must implement "
+"the org.jboss.ejb3.cache.Optimized interface:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:224
+#, no-c-format
+msgid ""
+"public interface Optimized {\n"
+"boolean isModified();\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:226
+#, no-c-format
+msgid ""
+"JBoss Cache provides the session state replication service for EJB 3.0 "
+"stateful session beans. The related MBean service is defined in the "
+"<literal>ejb3-clustered-sfsbcache-service.xml</literal> file in the "
+"<literal>deploy</literal> directory. The contents of the file are as follows."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_EJBs.xml:229
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<server>\n"
+" <mbean code=\"org.jboss..cache.TreeCache\"\n"
+" name=\"jboss.cache:service=EJB3SFSBClusteredCache\">\n"
+" \n"
+" <attribute name=\"ClusterName\">\n"
+" ${jboss.partition.name:DefaultPartition}-SFSBCache\n"
+" </attribute>\n"
+" <attribute name=\"IsolationLevel\">REPEATABLE_READ</"
+"attribute>\n"
+" <attribute name=\"CacheMode\">REPL_ASYNC</"
+"attribute> \n"
+" \n"
+" <!-- We want to activate/inactivate regions as beans "
+"are deployed --> \n"
+" <attribute name=\"UseRegionBasedMarshalling\">true</"
+"attribute> \n"
+" <!-- Must match the value of "
+"\"useRegionBasedMarshalling\" --> \n"
+" <attribute name=\"InactiveOnStartup\">true</"
+"attribute>\n"
+" \n"
+" <attribute name=\"ClusterConfig\">\n"
+" ... ...\n"
+" </attribute> \n"
+" \n"
+" <!-- The max amount of time (in milliseconds) we "
+"wait until the \n"
+" initial state (ie. the contents of the cache) are "
+"retrieved from \n"
+" existing members. --> \n"
+" <attribute name=\"InitialStateRetrievalTimeout"
+"\">17500</attribute>\n"
+" \n"
+" <!-- Number of milliseconds to wait until all "
+"responses for a\n"
+" synchronous call have been received.\n"
+" -->\n"
+" <attribute name=\"SyncReplTimeout\">17500</"
+"attribute>\n"
+" \n"
+" <!-- Max number of milliseconds to wait for a lock "
+"acquisition -->\n"
+" <attribute name=\"LockAcquisitionTimeout\">15000</"
+"attribute>\n"
+" \n"
+" <!-- Name of the eviction policy class. -->\n"
+" <attribute name=\"EvictionPolicyClass\">\n"
+" org.jboss.cache.eviction.LRUPolicy\n"
+" </attribute>\n"
+" \n"
+" <!-- Specific eviction policy configurations. This "
+"is LRU -->\n"
+" <attribute name=\"EvictionPolicyConfig\">\n"
+" <config>\n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</"
+"attribute>\n"
+" <name>statefulClustered</name> \n"
+" <!-- So default region would never timeout --"
+">\n"
+" <region name=\"/_default_\">\n"
+" <attribute name=\"maxNodes\">0</attribute>\n"
+" <attribute name=\"timeToIdleSeconds\">0</"
+"attribute>\n"
+" </region>\n"
+" </config>\n"
+" </attribute> \n"
+" \n"
+" <!-- Store passivated sessions to the file system --> \n"
+" <attribute name=\"CacheLoaderConfiguration\"> \n"
+" <config> \n"
+" \n"
+" <passivation>true</passivation> \n"
+" <shared>false</shared> \n"
+" \n"
+" <cacheloader> \n"
+" <class>org.jboss.cache.loader.FileCacheLoader</class> \n"
+" <!-- Passivate to the server data dir --> \n"
+" <properties> \n"
+" location=${jboss.server.data.dir}${/}sfsb \n"
+" </properties> \n"
+" <async>false</async> \n"
+" <fetchPersistentState>true</fetchPersistentState> \n"
+" <ignoreModifications>false</ignoreModifications> \n"
+" </cacheloader> \n"
+" \n"
+" </config> \n"
+" </attribute>\n"
+" </mbean>\n"
+"</server>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:235
+#, no-c-format
+msgid ""
+"The configuration attributes in this MBean are essentially the same as the "
+"attributes in the standard JBoss Cache <literal>TreeCache</literal> MBean "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:240
+#, no-c-format
+msgid ""
+"The cache is configured to support eviction. The EJB3 SFSB container uses "
+"the JBoss Cache eviction mechanism to manage SFSB passivation. When beans "
+"are deployed, the EJB container will programatically add eviction regions to "
+"the cache, one region per bean type."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_EJBs.xml:244
+#, no-c-format
+msgid ""
+"A JBoss Cache CacheLoader is also configured; again to support SFSB "
+"passivation. When beans are evicted from the cache, the cache loader "
+"passivates them to a persistent store; in this case to the filesystem in the "
+"$JBOSS_HOME/server/all/data/sfsb directory. JBoss Cache supports a variety "
+"of different CacheLoader implementations that know how to store data to "
+"different persistent store types; see the JBoss Cache documentation for "
+"details. However, if you change the CacheLoaderConfiguration, be sure that "
+"you do not use a shared store (e.g., a single schema in a shared database.) "
+"Each node in the cluster must have its own persistent store, otherwise as "
+"nodes independently passivate and activate clustered beans, they will "
+"corrupt each others data."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Entity_EJBs.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Entity_EJBs.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Entity_EJBs.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,715 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:5
+#, no-c-format
+msgid "Clustered Entity EJBs"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:6
+#, no-c-format
+msgid ""
+"In a JBoss AS cluster, the entity bean instance caches need to be kept in "
+"sync across all nodes. If an entity bean provides remote services, the "
+"service methods need to be load balanced as well."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:8
+#, no-c-format
+msgid ""
+"To use a clustered entity bean, the application does not need to do anything "
+"special, except for looking up EJB 2.x remote bean references from the "
+"clustered HA-JNDI."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:10
+#, no-c-format
+msgid "Entity Bean in EJB 2.x"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:11
+#, no-c-format
+msgid ""
+"First of all, it is worth noting that clustering 2.x entity beans is a bad "
+"thing to do. Its exposes elements that generally are too fine grained for "
+"use as remote objects to clustered remote objects and introduces data "
+"synchronization problems that are non-trivial. Do NOT use EJB 2.x entity "
+"bean clustering unless you fit into the sepecial case situation of read-"
+"only, or one read-write node with read-only nodes synched with the cache "
+"invalidation services."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:13
+#, no-c-format
+msgid ""
+"To cluster EJB 2.x entity beans, you need to add the <literal><"
+"clustered></literal> element to the application's <literal>jboss.xml</"
+"literal> descriptor file. Below is a typical <literal>jboss.xml</literal> "
+"file."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:16
+#, no-c-format
+msgid ""
+"<jboss> \n"
+" <enterprise-beans> \n"
+" <entity> \n"
+" <ejb-name>nextgen.EnterpriseEntity</ejb-"
+"name> \n"
+" <jndi-name>nextgen.EnterpriseEntity</jndi-"
+"name> \n"
+" <clustered>True</clustered> \n"
+" <cluster-config> \n"
+" <partition-name>DefaultPartition</partition-"
+"name> \n"
+" <home-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces."
+"RoundRobin \n"
+" </home-load-balance-policy> \n"
+" <bean-load-balance-policy> \n"
+" org.jboss.ha.framework.interfaces."
+"FirstAvailable \n"
+" </bean-load-balance-policy> \n"
+" </cluster-config> \n"
+" </entity> \n"
+" </enterprise-beans> \n"
+"</jboss>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:17
+#, no-c-format
+msgid ""
+"The EJB 2.x entity beans are clustered for load balanced remote invocations. "
+"All the bean instances are synchronized to have the same contents on all "
+"nodes."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:19
+#, no-c-format
+msgid ""
+"However, clustered EJB 2.x Entity Beans do not have a distributed locking "
+"mechanism or a distributed cache. They can only be synchronized by using row-"
+"level locking at the database level (see <literal><row-lock></literal> "
+"in the CMP specification) or by setting the Transaction Isolation Level of "
+"your JDBC driver to be <literal>TRANSACTION_SERIALIZABLE</literal>. Because "
+"there is no supported distributed locking mechanism or distributed cache "
+"Entity Beans use Commit Option \"B\" by default (See <literal>standardjboss."
+"xml</literal> and the container configurations Clustered CMP 2.x EntityBean, "
+"Clustered CMP EntityBean, or Clustered BMP EntityBean). It is not "
+"recommended that you use Commit Option \"A\" unless your Entity Bean is read-"
+"only. (There are some design patterns that allow you to use Commit Option \"A"
+"\" with read-mostly beans. You can also take a look at the Seppuku pattern "
+"<ulink url=\"http://dima.dhs.org/misc/readOnlyUpdates.html\"></ulink>. JBoss "
+"may incorporate this pattern into later versions.)"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:31
+#, no-c-format
+msgid ""
+"If you are using Bean Managed Persistence (BMP), you are going to have to "
+"implement synchronization on your own. The MVCSoft CMP 2.0 persistence "
+"engine (see <ulink url=\"http://www.jboss.org/jbossgroup/partners.jsp\"></"
+"ulink>) provides different kinds of optimistic locking strategies that can "
+"work in a JBoss cluster."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:37
+#, no-c-format
+msgid "Entity Bean in EJB 3.0"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:39
+#, no-c-format
+msgid ""
+"In EJB 3.0, the entity beans primarily serve as a persistence data model. "
+"They do not provide remote services. Hence, the entity bean clustering "
+"service in EJB 3.0 primarily deals with distributed caching and replication, "
+"instead of load balancing."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:45
+#, no-c-format
+msgid "Configure the distributed cache"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:46
+#, no-c-format
+msgid ""
+"To avoid round trips to the database, you can use a cache for your entities. "
+"JBoss EJB 3.0 entity beans are implemented by Hibernate, which has support "
+"for a second-level cache. The Hibernate setup used for the JBoss EJB 3.0 "
+"implementation uses JBoss Cache as its underlying second-level cache "
+"implementation. The second-level cache provides the following "
+"functionalities."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:49
+#, no-c-format
+msgid ""
+"If you persist a cache enabled entity bean instance to the database via the "
+"entity manager the entity will inserted into the cache."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:53
+#, no-c-format
+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 ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:57
+#, no-c-format
+msgid ""
+"If you remove an entity bean instance from the database via the entity "
+"manager the entity will removed from the cache."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:61
+#, no-c-format
+msgid ""
+"If loading a cached entity from the database via the entity manager, and "
+"that entity does not exist in the database, it will be inserted into the "
+"cache."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:65
+#, no-c-format
+msgid ""
+"The JBoss Cache service for EJB 3.0 entity beans is configured in a "
+"<literal>TreeCache</literal> MBean in the <literal>deploy/ejb3-entity-cache-"
+"service.xml</literal> file. The name of the cache MBean service is "
+"<literal>jboss.cache:service=EJB3EntityTreeCache</literal>. Below are the "
+"contents of the <literal>ejb3-entity-cache-service.xml</literal> file in the "
+"standard JBoss distribution. Again, we omitted the JGroups configuration "
+"element <literal>ClusterConfig</literal>."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:71
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+" <server>\n"
+" <mbean code=\"org.jboss.cache.TreeCache\" \n"
+" name=\"jboss.cache:service=EJB3EntityTreeCache\">\n"
+" \n"
+" <depends>jboss:service=Naming</depends>\n"
+" <depends>jboss:service=TransactionManager</depends> \n"
+" \n"
+" <!-- Name of cluster. Needs to be the same on all nodes in the clusters, \n"
+" in order to find each other --> \n"
+" <attribute name=\"ClusterName\">\n"
+" ${jboss.partition.name:DefaultPartition}-EntityCache\n"
+" </attribute>\n"
+" \n"
+" <!-- Configure the TransactionManager -->\n"
+" <attribute name=\"TransactionManagerLookupClass\">\n"
+" org.jboss.cache.JBossTransactionManagerLookup\n"
+" </attribute>\n"
+" \n"
+" <attribute name=\"IsolationLevel\">REPEATABLE_READ</attribute>\n"
+" <attribute name=\"CacheMode\">REPL_SYNC</attribute> \n"
+" \n"
+" <!-- Must be true if any entity deployment uses a scoped "
+"classloader --> \n"
+" <attribute name=\"UseRegionBasedMarshalling\">true</attribute> \n"
+" <!-- Must match the value of \"useRegionBasedMarshalling\" --> \n"
+" <attribute name=\"InactiveOnStartup\">true</attribute>\n"
+" \n"
+" <attribute name=\"ClusterConfig\">\n"
+" ... ...\n"
+" </attribute>\n"
+" \n"
+" <attribute name=\"InitialStateRetrievalTimeout\">17500</attribute>\n"
+" <attribute name=\"SyncReplTimeout\">17500</attribute>\n"
+" <attribute name=\"LockAcquisitionTimeout\">15000</attribute>\n"
+" \n"
+" <attribute name=\"EvictionPolicyClass\">\n"
+" org.jboss.cache.eviction.LRUPolicy\n"
+" </attribute>\n"
+" \n"
+" <!-- Specific eviction policy configurations. This is LRU -->\n"
+" <attribute name=\"EvictionPolicyConfig\">\n"
+" <config>\n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</attribute>\n"
+" <!-- Cache wide default -->\n"
+" <region name=\"/_default_\">\n"
+" <attribute name=\"maxNodes\">5000</attribute>\n"
+" <attribute name=\"timeToLiveSeconds\">1000</attribute>\n"
+" </region>\n"
+" </config>\n"
+" </attribute>\n"
+" </mbean>\n"
+"</server>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:73
+#, no-c-format
+msgid ""
+"This is a replicated cache, so, if running within a cluster, and the cache "
+"is updated, changes to the entries in one node will be replicated to the "
+"corresponding entries in the other nodes in the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:76
+#, no-c-format
+msgid ""
+"JBoss Cache allows you to specify timeouts to cached entities. Entities not "
+"accessed within a certain amount of time are dropped from the cache in order "
+"to save memory. The above configuration sets up a default configuration "
+"region that says that at most the cache will hold 5000 nodes, after which "
+"nodes will start being evicted from memory, least-recently used nodes last. "
+"Also, if any node has not been accessed within the last 1000 seconds, it "
+"will be evicted from memory. In general, a node in the cache represents a "
+"cached item (entity, collection, or query result set), although there are "
+"also a few other node that are used for internal purposes. If the above "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:80
+#, no-c-format
+msgid ""
+"Now, we have JBoss Cache configured to support distributed caching of EJB "
+"3.0 entity beans. We still have to configure individual entity beans to use "
+"the cache service."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:83
+#, no-c-format
+msgid "Configure the entity beans for cache"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:84
+#, no-c-format
+msgid ""
+"You define your entity bean classes the normal way. Future versions of JBoss "
+"EJB 3.0 will support annotating entities and their relationship collections "
+"as cached, but for now you have to configure the underlying hibernate engine "
+"directly. Take a look at the <literal>persistence.xml</literal> file, which "
+"configures the caching options for hibernate via its optional "
+"<literal>property</literal> elements. The following element in "
+"<literal>persistence.xml</literal> defines that caching should be enabled:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:90
+#, no-c-format
+msgid ""
+"<!-- Clustered cache with TreeCache -->\n"
+"<property name=\"cache.provider_class\">\n"
+" org.jboss.ejb3.entity.TreeCacheProviderHook\n"
+"</property>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:91
+#, no-c-format
+msgid ""
+"The following property element defines the object name of the cache to be "
+"used, i.e., the name of the TreeCache MBean shown above."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:92
+#, no-c-format
+msgid ""
+"<property name=\"treecache.mbean.object_name\">\n"
+" jboss.cache:service=EJB3EntityTreeCache\n"
+"</property>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:93
+#, no-c-format
+msgid ""
+"Finally, you should give a “region_prefix” to this configuration. This "
+"ensures that all cached items associated with this persistence.xml are "
+"properly grouped together in JBoss Cache. The jboss.cache:"
+"service=EJB3EntityTreeCache cache is a shared resource, potentially used by "
+"multiple persistence units. The items cached in that shared cache need to be "
+"properly grouped to allow the cache to properly manage classloading. <"
+"property name=\"hibernate.cache.region_prefix\" value=\"myprefix\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:97
+#, no-c-format
+msgid ""
+"If you do not provide a region prefix, JBoss will automatically provide one "
+"for you, building it up from the name of the EAR (if any) and the name of "
+"the JAR that includes the persistence.xml. For example, a persistence.xml "
+"packaged in foo.ear, bar.jar would be given “foo_ear,bar_jar” as its region "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:105
+#, no-c-format
+msgid ""
+"Next we need to configure what entities be cached. The default is to not "
+"cache anything, even with the settings shown above. We use the <literal>@org."
+"hibernate.annotations.Cache</literal> annotation to tag entity beans that "
+"needs to be cached."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:106
+#, no-c-format
+msgid ""
+"@Entity \n"
+"@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) \n"
+"public class Account implements Serializable { \n"
+" // ... ... \n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:107
+#, no-c-format
+msgid ""
+"A very simplified rule of thumb is that you will typically want to do "
+"caching for objects that rarely change, and which are frequently read. You "
+"can fine tune the cache for each entity bean in the <literal>ejb3-entity-"
+"cache-service.xml</literal> configuration file. For instance, you can "
+"specify the size of the cache. If there are too many objects in the cache, "
+"the cache could evict oldest objects (or least used objects, depending on "
+"configuration) to make room for new objects. Assuming the region_prefix "
+"specified in <literal>persistence.xml</literal> was myprefix, the default "
+"name of the cache region for the <literal>com.mycompany.entities.Account</"
+"literal> entity bean <literal>/myprefix/com/mycompany/entities/Account</"
+"literal>."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:109
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<server> \n"
+" <mbean code=\"org.jboss.cache.TreeCache\" \n"
+" name=\"jboss.cache:service=EJB3EntityTreeCache\"> \n"
+" ... ... \n"
+" <attribute name=\"EvictionPolicyConfig\"> \n"
+" <config> \n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</"
+"attribute> \n"
+" <region name=\"/_default_\"> \n"
+" <attribute name=\"maxNodes\">5000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">1000</attribute> \n"
+" </region> \n"
+" <!-- Separate eviction rules for Account entities -->\n"
+" <region name=\"/myprefix/com/mycompany/entities/"
+"Account\"> \n"
+" <attribute name=\"maxNodes\">10000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">5000</attribute> \n"
+" </region> \n"
+" ... ... \n"
+" </config> \n"
+" </attribute> \n"
+" </mbean> \n"
+"</server>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:112
+#, no-c-format
+msgid ""
+"If you do not specify a cache region for an entity bean class, all instances "
+"of this class will be cached in the <literal>/_default</literal> region as "
+"defined above. The @Cache annotation exposes an optional attribute “region” "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:115
+#, no-c-format
+msgid ""
+"@Entity \n"
+"@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL,\n"
+"region=”Account”) \n"
+"public class Account implements Serializable { \n"
+"// ... ... \n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:116
+#, no-c-format
+msgid "The eviction configuration would then become:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:117
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<server> \n"
+" <mbean code=\"org.jboss.cache.TreeCache\" \n"
+" name=\"jboss.cache:service=EJB3EntityTreeCache\"> \n"
+" ... ... \n"
+" <attribute name=\"EvictionPolicyConfig\"> \n"
+" <config> \n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</attribute> \n"
+" <region name=\"/_default_\"> \n"
+" <attribute name=\"maxNodes\">5000</attribute> \n"
+" <attribute name=\"timeToLiveSeconds\">1000</attribute> \n"
+" </region> \n"
+" <!-- Separate eviction rules for Account entities -->\n"
+" <region name=\"/myprefix/Account\"> \n"
+" <attribute name=\"maxNodes\">10000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds\">5000</"
+"attribute> \n"
+" </region> \n"
+" ... ... \n"
+" </config> \n"
+" </attribute> \n"
+" </mbean> \n"
+"</server>]]>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Entity_EJBs.xml:122
+#, no-c-format
+msgid "Query result caching"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:123
+#, no-c-format
+msgid ""
+"The EJB3 Query API also provides means for you to save in the second-level "
+"cache the results (i.e., collections of primary keys of entity beans, or "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:126
+#, no-c-format
+msgid ""
+"First, in persistence.xml you need to tell Hibernate to enable query caching:"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_Entity_EJBs.xml:129
+#, no-c-format
+msgid ""
+"<property name=\"hibernate.cache.use_query_cache\" value=\"true\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:130
+#, no-c-format
+msgid ""
+"Next, you create a named query associated with an entity, and tell Hibernate "
+"you want to cache the results of that query:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:133
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"@Entity\n"
+"@Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL,\n"
+"region=”Account”)\n"
+"@NamedQueries({\n"
+"@NamedQuery(name=\"account.bybranch\",\n"
+"query=\"select acct from Account as acct where acct.branch = ?1\",\n"
+"hints={@QueryHint(name=\"org.hibernate.cacheable\",value=\"true"
+"\")}) \n"
+"})\n"
+"public class Account implements Serializable { \n"
+"// ... ... \n"
+"}]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:135
+#, no-c-format
+msgid ""
+"The @NamedQueries, @NamedQuery and @QueryHint annotations are all in the "
+"javax.persistence package.See the Hibernate and EJB3 documentation for more "
+"on how to use EJB3 queries and on how to instruct EJB3 to cache queries."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:138
+#, no-c-format
+msgid ""
+"By default, Hibernate stores query results in JBoss Cache in a region named "
+"{region_prefix}/org/hibernate/cache/StandardQueryCache. Based on this, you "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:142
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<server> \n"
+" <mbean code=\"org.jboss.cache.TreeCache\" \n"
+" name=\"jboss.cache:service=EJB3EntityTreeCache\">\n"
+" ... ... \n"
+" <attribute name=\"EvictionPolicyConfig\"> \n"
+" <config> \n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</"
+"attribute> \n"
+" <region name=\"/_default_\"> \n"
+" <attribute name=\"maxNodes\">5000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">1000</attribute> \n"
+" </region> \n"
+" <!-- Separate eviction rules for Account "
+"entities -->\n"
+" <region name=\"/myprefix/Account\"> \n"
+" <attribute name=\"maxNodes"
+"\">10000</attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">5000</attribute> \n"
+" </region>\n"
+" <!-- Cache queries for 10 minutes -->\n"
+" <region name=\"/myprefix/org/hibernate/"
+"cache/StandardQueryCache\"> \n"
+" <attribute name=\"maxNodes\">100</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">600</attribute> \n"
+" </region> \n"
+" ... ... \n"
+" </config> \n"
+" </attribute> \n"
+" </mbean> \n"
+"</server>\n"
+" ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:144
+#, no-c-format
+msgid ""
+"The @NamedQuery.hints attribute shown above takes an array of vendor-"
+"specific @QueryHints as a value. Hibernate accepts the “org.hibernate."
+"cacheRegion” query hint, where the value is the name of a cache region to "
+"use instead ofthe default /org/hibernate/cache/StandardQueryCache. For "
+"example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:147
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+" @Entity\n"
+" @Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL,\n"
+" region=”Account”)\n"
+" @NamedQueries({\n"
+" @NamedQuery(name=\"account.bybranch\",\n"
+" query=\"select acct from Account as acct where acct.branch = ?1\",\n"
+" hints={@QueryHint(name=\"org.hibernate.cacheable\",value=\"true\"),\n"
+" @QueryHint(name=”org.hibernate.cacheRegion,value=”Queries”)\n"
+" }) \n"
+" })\n"
+" public class Account implements Serializable { \n"
+" // ... ... \n"
+" }]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Entity_EJBs.xml:148
+#, no-c-format
+msgid "The related eviction configuration:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Entity_EJBs.xml:151
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<server> \n"
+" <mbean code=\"org.jboss.cache.TreeCache\" \n"
+" name=\"jboss.cache:service=EJB3EntityTreeCache\">\n"
+" ... ... \n"
+" <attribute name=\"EvictionPolicyConfig\"> \n"
+" <config> \n"
+" <attribute name=\"wakeUpIntervalSeconds\">5</"
+"attribute> \n"
+" <region name=\"/_default_\"> \n"
+" <attribute name=\"maxNodes\">5000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">1000</attribute> \n"
+" </region> \n"
+" <!-- Separate eviction rules for Account "
+"entities -->\n"
+" <region name=\"/myprefix/Account\"> \n"
+" <attribute name=\"maxNodes\">10000</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">5000</attribute> \n"
+" </region>\n"
+" <!-- Cache queries for 10 minutes -->\n"
+" <region name=\"/myprefix/Queries\"> \n"
+" <attribute name=\"maxNodes\">100</"
+"attribute> \n"
+" <attribute name=\"timeToLiveSeconds"
+"\">600</attribute> \n"
+" </region> \n"
+" ... ... \n"
+" </config> \n"
+" </attribute> \n"
+" </mbean> \n"
+"</server>]]>"
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_HTTP.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_HTTP.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,1679 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:5
+#, no-c-format
+msgid "HTTP Services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:6
+#, no-c-format
+msgid ""
+"HTTP session replication is used to replicate the state associated with your "
+"web clients on other nodes of a cluster. Thus, in the event one of your node "
+"crashes, another node in the cluster will be able to recover. Two distinct "
+"functions must be performed:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:11
+#, no-c-format
+msgid "Session state replication"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:14
+#, no-c-format
+msgid "Load-balancing of incoming invocations"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:17
+#, no-c-format
+msgid ""
+"State replication is directly handled by JBoss. When you run JBoss in the "
+"<literal>all</literal> configuration, session state replication is enabled "
+"by default. Just configure your web application as distributable in its "
+"<filename>web.xml</filename> (see below), deploy it, and its session state "
+"is automtically replicated across all JBoss instances in the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:19
+#, no-c-format
+msgid ""
+"However, load-balancing is a different story; it is not handled by JBoss "
+"itself and requires an external load balancer. aThis function could be "
+"provided by specialized hardware switches or routers (Cisco LoadDirector for "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:22 Clustering_Guide_HTTP.xml:447
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:24
+#, no-c-format
+msgid ""
+"A load-balancer tracks HTTP requests and, depending on the session to which "
+"the request is linked, it dispatches the request to the appropriate node. "
+"This is called load-balancing with sticky-sessions: once a session is "
+"created on a node, every future request will also be processed by that same "
+"node. Using a load-balancer that supports sticky-sessions but not "
+"configuring your web application for session replication allows you to scale "
+"very well by avoiding the cost of session state replication: each query will "
+"always be handled by the same node. But in case a node dies, the state of "
+"all client sessions hosted by this node (the shopping carts, for example) "
+"will be lost and the clients will most probably need to login on another "
+"node and restart with a new session. In many situations, it is acceptable "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:26
+#, no-c-format
+msgid "Configuring load balancing using Apache and mod_jk"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:28
+#, no-c-format
+msgid ""
+"Apache is a well-known web server which can be extended by plugging in "
+"modules. One of these modules, mod_jk has been specifically designed to "
+"allow the forwarding of requests from Apache to a Servlet container. "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:33
+#, no-c-format
+msgid "Download the software"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:34
+#, no-c-format
+msgid ""
+"First of all, make sure that you have Apache installed. You can download "
+"Apache directly from Apache web site at <literal>http://httpd.apache.org/</"
+"literal>. Its installation is pretty straightforward and requires no "
+"specific configuration. As several versions of Apache exist, we advise you "
+"to use version 2.0.x. We will consider, for the next sections, that you have "
+"installed Apache in the <literal>APACHE_HOME</literal> directory."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:39
+#, no-c-format
+msgid ""
+"Next, download mod_jk binaries. Several versions of mod_jk exist as well. We "
+"strongly advise you to use mod_jk 1.2.x, as both mod_jk and mod_jk2 are "
+"deprecated, unsupported and no further developments are going on in the "
+"community. The mod_jk 1.2.x binary can be downloaded from <literal>http://"
+"www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</literal>. Rename "
+"the downloaded file to <literal>mod_jk.so</literal> and copy it under "
+"<literal>APACHE_HOME/modules/</literal>."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:47
+#, no-c-format
+msgid "Configure Apache to load mod_jk"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:48
+#, no-c-format
+msgid ""
+"Modify APACHE_HOME/conf/httpd.conf and add a single line at the end of the "
+"file:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:49
+#, no-c-format
+msgid ""
+"# Include mod_jk's specific configuration file \n"
+"Include conf/mod-jk.conf"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:50
+#, no-c-format
+msgid ""
+"Next, create a new file named <literal>APACHE_HOME/conf/mod-jk.conf</"
+"literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:51
+#, no-c-format
+msgid ""
+"# Load mod_jk module\n"
+"# Specify the filename of the mod_jk lib\n"
+"LoadModule jk_module modules/mod_jk.so\n"
+" \n"
+"# Where to find workers.properties\n"
+"JkWorkersFile conf/workers.properties\n"
+"\n"
+"# Where to put jk logs\n"
+"JkLogFile logs/mod_jk.log\n"
+" \n"
+"# Set the jk log level [debug/error/info]\n"
+"JkLogLevel info \n"
+" \n"
+"# Select the log format\n"
+"JkLogStampFormat \"[%a %b %d %H:%M:%S %Y]\"\n"
+" \n"
+"# JkOptions indicates to send SSK KEY SIZE\n"
+"JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories\n"
+" \n"
+"# JkRequestLogFormat\n"
+"JkRequestLogFormat \"%w %V %T\"\n"
+" \n"
+"# Mount your applications\n"
+"JkMount /application/* loadbalancer\n"
+" \n"
+"# You can use external file for mount points.\n"
+"# It will be checked for updates each 60 seconds.\n"
+"# The format of the file is: /url=worker\n"
+"# /examples/*=loadbalancer\n"
+"JkMountFile conf/uriworkermap.properties \n"
+"\n"
+"# Add shared memory.\n"
+"# This directive is present with 1.2.10 and\n"
+"# later versions of mod_jk, and is needed for\n"
+"# for load balancing to work properly\n"
+"JkShmFile logs/jk.shm \n"
+" \n"
+"# Add jkstatus for managing runtime data\n"
+"<Location /jkstatus/>\n"
+" JkMount status\n"
+" Order deny,allow\n"
+" Deny from all\n"
+" Allow from 127.0.0.1\n"
+"</Location>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:52
+#, no-c-format
+msgid "Please note that two settings are very important:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:55
+#, no-c-format
+msgid ""
+"The <literal>LoadModule</literal> directive must reference the mod_jk "
+"library you have downloaded in the previous section. You must indicate the "
+"exact same name with the \"modules\" file path prefix."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:60
+#, no-c-format
+msgid ""
+"The <literal>JkMount</literal> directive tells Apache which URLs it should "
+"forward to the mod_jk module (and, in turn, to the Servlet containers). In "
+"the above file, all requests with URL path <literal>/application/*</literal> "
+"are sent to the mod_jk load-balancer. This way, you can configure Apache to "
+"server static contents (or PHP contents) directly and only use the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:68
+#, no-c-format
+msgid ""
+"In addition to the <literal>JkMount</literal> directive, you can also use "
+"the <literal>JkMountFile</literal> directive to specify a mount points "
+"configuration file, which contains multiple Tomcat forwarding URL mappings. "
+"You just need to create a <literal>uriworkermap.properties</literal> file in "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:74
+#, no-c-format
+msgid ""
+"# Simple worker configuration file\n"
+"\n"
+"# Mount the Servlet context to the ajp13 worker\n"
+"/jmx-console=loadbalancer\n"
+"/jmx-console/*=loadbalancer\n"
+"/web-console=loadbalancer\n"
+"/web-console/*=loadbalancer"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:75
+#, no-c-format
+msgid ""
+"This will configure mod_jk to forward requests to <literal>/jmx-console</"
+"literal> and <literal>/web-console</literal> to Tomcat."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:77
+#, no-c-format
+msgid ""
+"You will most probably not change the other settings in <literal>mod_jk."
+"conf</literal>. They are used to tell mod_jk where to put its logging file, "
+"which logging level to use and so on."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:81
+#, no-c-format
+msgid "Configure worker nodes in mod_jk"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:82
+#, no-c-format
+msgid ""
+"Next, you need to configure mod_jk workers file <literal>conf/workers."
+"properties</literal>. This file specifies where the different Servlet "
+"containers are located and how calls should be load-balanced across them. "
+"The configuration file contains one section for each target servlet "
+"container and one global section. For a two nodes setup, the file could look "
+"like this:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:87
+#, no-c-format
+msgid ""
+"# Define list of workers that will be used\n"
+"# for mapping requests\n"
+"worker.list=loadbalancer,status\n"
+"\n"
+"# Define Node1\n"
+"# modify the host as your host IP or DNS name.\n"
+"worker.node1.port=8009\n"
+"worker.node1.host=node1.mydomain.com \n"
+"worker.node1.type=ajp13\n"
+"worker.node1.lbfactor=1\n"
+"worker.node1.cachesize=10\n"
+"\n"
+"# Define Node2\n"
+"# modify the host as your host IP or DNS name.\n"
+"worker.node2.port=8009\n"
+"worker.node2.host= node2.mydomain.com\n"
+"worker.node2.type=ajp13\n"
+"worker.node2.lbfactor=1\n"
+"worker.node2.cachesize=10\n"
+"\n"
+"# Load-balancing behaviour\n"
+"worker.loadbalancer.type=lb\n"
+"worker.loadbalancer.balance_workers=node1,node2\n"
+"worker.loadbalancer.sticky_session=1\n"
+"#worker.list=loadbalancer\n"
+"\n"
+"# Status worker for managing load balancer\n"
+"worker.status.type=status"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:88
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:91
+#, no-c-format
+msgid ""
+"In the <literal>works.properties</literal> file, each node is defined using "
+"the <literal>worker.XXX</literal> naming convention where <literal>XXX</"
+"literal> represents an arbitrary name you choose for each of the target "
+"Servlet containers. For each worker, you must specify the host name (or IP "
+"address) and the port number of the AJP13 connector running in the Servlet "
+"container."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:96
+#, no-c-format
+msgid ""
+"The <literal>lbfactor</literal> attribute is the load-balancing factor for "
+"this specific worker. It is used to define the priority (or weight) a node "
+"should have over other nodes. The higher this number is for a given worker "
+"relative to the other workers, the more HTTP requests the worker will "
+"receive. This setting can be used to differentiate servers with different "
+"processing power."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:98
+#, no-c-format
+msgid ""
+"The <literal>cachesize</literal> attribute defines the size of the thread "
+"pools associated to the Servlet container (i.e. the number of concurrent "
+"requests it will forward to the Servlet container). Make sure this number "
+"does not outnumber the number of threads configured on the AJP13 connector "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:104
+#, no-c-format
+msgid ""
+"The last part of the <literal>conf/workers.properties</literal> file defines "
+"the loadbalancer worker. The only thing you must change is the "
+"<literal>worker.loadbalancer.balanced_workers</literal> line: it must list "
+"all workers previously defined in the same file: load-balancing will happen "
+"over these workers."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:108
+#, no-c-format
+msgid ""
+"The <literal>sticky_session</literal> property specifies the cluster "
+"behavior for HTTP sessions. If you specify <literal>worker.loadbalancer."
+"sticky_session=0</literal>, each request will be load balanced between node1 "
+"and node2; i.e., different requests for the same session will go to "
+"different servers. But when a user opens a session on one server, it is "
+"always necessary to always forward this user's requests to the same server, "
+"as long as that server is available. This is called a \"sticky session\", as "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:113
+#, no-c-format
+msgid ""
+"A non-loadbalanced setup with a single node requires a <literal>worker."
+"list=node1</literal> entry."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:118
+#, no-c-format
+msgid "Configuring JBoss to work with mod_jk"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:119
+#, no-c-format
+msgid ""
+"Finally, we must configure the JBoss Tomcat instances on all clustered nodes "
+"so that they can expect requests forwarded from the mod_jk loadbalancer."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:121
+#, no-c-format
+msgid ""
+"On each clustered JBoss node, we have to name the node according to the name "
+"specified in <literal>workers.properties</literal>. For instance, on JBoss "
+"instance node1, edit the <literal>JBOSS_HOME/server/all/deploy/jboss-web."
+"deployer/server.xml</literal> file (replace <literal>/all</literal> with "
+"your own server name if necessary). Locate the <literal><Engine></"
+"literal> element and add an attribute <literal>jvmRoute</literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:126
+#, no-c-format
+msgid ""
+"<Engine name=\"jboss.web\" defaultHost=\"localhost\" jvmRoute=\"node1"
+"\">\n"
+"... ...\n"
+"</Engine>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:127
+#, no-c-format
+msgid ""
+"You also need to be sure the AJP connector in server.xml is enabled (i.e., "
+"uncommented). It is enabled by default."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:129
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<!-- Define an AJP 1.3 Connector on port 8009 --> \n"
+"<Connector port=\"8009\" address=\"${jboss.bind.address}\" protocol=\"AJP/1.3"
+"\" \n"
+"emptySessionPath=\"true\" enableLookups=\"false\" redirectPort=\"8443\" /> ]]"
+">"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:131
+#, no-c-format
+msgid ""
+"Then, for each JBoss Tomcat instance in the cluster, we need to tell it that "
+"mod_jk is in use, so it can properly manage the <literal>jvmRoute</literal> "
+"appended to its session cookies so that mod_jk can properly route incoming "
+"requests. Edit the <literal>JBOSS_HOME/server/all/deploy/jbossweb-tomcat50."
+"sar/META-INF/jboss-service.xml</literal> file (replace <literal>/all</"
+"literal> with your own server name). Locate the <literal><attribute></"
+"literal> element with a name of <literal>UseJK</literal>, and set its value "
+"to <literal>true</literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:136
+#, no-c-format
+msgid "<attribute name=\"UseJK\">true</attribute>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:137
+#, no-c-format
+msgid ""
+"At this point, you have a fully working Apache+mod_jk load-balancer setup "
+"that will balance call to the Servlet containers of your cluster while "
+"taking care of session stickiness (clients will always use the same Servlet "
+"container)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:141
+#, no-c-format
+msgid ""
+"For more updated information on using mod_jk 1.2 with JBoss Tomcat, please "
+"refer to the JBoss wiki page at <literal>http://wiki.jboss.org/wiki/Wiki.jsp?"
+"page=UsingMod_jk1.2WithJBoss</literal>."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:149
+#, no-c-format
+msgid "Configuring HTTP session state replication"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:150
+#, no-c-format
+msgid ""
+"The preceding discussion has been focused on using mod_jk as a load "
+"balancer. The content of the remainder our discussion of clustering HTTP "
+"services in JBoss AS applies no matter what load balancer is used."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:153
+#, no-c-format
+msgid ""
+"In <xref linkend=\"clustering-http-nodes\"/>, we covered how to use sticky "
+"sessions to make sure that a client in a session always hits the same server "
+"node in order to maintain the session state. However, sticky sessions by "
+"themselves are not an ideal solution. If a node goes down, all its session "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:155
+#, no-c-format
+msgid ""
+"The <literal>jboss.cache:service=TomcatClusteringCache</literal> MBean makes "
+"use of JBoss Cache to provide HTTP session replication services to the JBoss "
+"Tomcat cluster. This MBean is defined in the <literal>deploy/jboss-web-"
+"cluster.sar/META-INF/jboss-service.xml file</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:158
+#, no-c-format
+msgid ""
+"Before AS 4.2.0, the location of the HTTP session cache configuration file "
+"was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. "
+"Prior to AS 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-"
+"service.xml</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:160
+#, no-c-format
+msgid ""
+"Below is a typical <literal>deploy/jbossweb-cluster.sar/META-INF/jboss-"
+"service.xml</literal> file. The configuration attributes in the "
+"<literal>TomcatClusteringCache</literal> MBean are very similar to those in "
+"the JBoss AS cache configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:163
+#, no-c-format
+msgid ""
+"<mbean code=\"org.jboss.cache.aop.TreeCacheAop\"\n"
+" name=\"jboss.cache:service=TomcatClusteringCache\">\n"
+"\n"
+" <depends>jboss:service=Naming</depends>\n"
+" <depends>jboss:service=TransactionManager</depends>\n"
+" <depends>jboss.aop:service=AspectDeployer</depends>\n"
+"\n"
+" <attribute name=\"TransactionManagerLookupClass\">\n"
+" org.jboss.cache.BatchModeTransactionManagerLookup\n"
+" </attribute>\n"
+" \n"
+" <attribute name=\"IsolationLevel\">REPEATABLE_READ</"
+"attribute>\n"
+" \n"
+" <attribute name=\"CacheMode\">REPL_ASYNC</attribute>\n"
+" \n"
+" <attribute name=\"ClusterName\">\n"
+" Tomcat-${jboss.partition.name:Cluster}\n"
+" </attribute>\n"
+" \n"
+" <attribute name=\"UseMarshalling\">false</attribute>\n"
+" \n"
+" <attribute name=\"InactiveOnStartup\">false</attribute>\n"
+" \n"
+" <attribute name=\"ClusterConfig\">\n"
+" ... ...\n"
+" </attribute>\n"
+" \n"
+" \n"
+" <attribute name=\"LockAcquisitionTimeout\">15000</"
+"attribute>\n"
+" <attribute name=\"SyncReplTimeout\">20000</attribute>\n"
+"</mbean>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:165
+#, no-c-format
+msgid ""
+"Note that the value of the mbean element's code attribute is org.jboss.cache."
+"aop.TreeCacheAop, which is different from the other JBoss Cache Mbeans used "
+"in JBoss AS. This is because FIELD granularity HTTP session replication "
+"(covered below) needs the added features of the <literal>TreeCacheAop</"
+"literal> (a.k.a. <literal>PojoCache</literal>) class."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:168
+#, no-c-format
+msgid ""
+"The details of all the configuration options for a TreeCache MBean are "
+"covered in the JBoss Cache documentation. Below, we will just discuss "
+"several attributes that are most relevant to the HTTP cluster session "
+"replication."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:171
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">TransactionManagerLookupClass</emphasis> sets the "
+"transaction manager factory. The default value is <literal>org.jboss.cache."
+"BatchModeTransactionManagerLookup</literal>. It tells the cache NOT to "
+"participate in JTA-specific transactions. Instead, the cache manages its own "
+"transactions. Please do not change this."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:178
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">CacheMode</emphasis> controls how the cache is "
+"replicated. The valid values are <literal>REPL_SYNC</literal> and "
+"<literal>REPL_ASYNC</literal>. With either setting the client request thread "
+"updates the local cache with the current sesssion contents and then sends a "
+"message to the caches on the other members of the cluster, telling them to "
+"make the same change. With REPL_ASYNC (the default) the request thread "
+"returns as soon as the update message has been put on the network. With "
+"REPL_SYNC, the request thread blocks until it gets a reply message from all "
+"cluster members, informing it that the update was successfully applied. "
+"Using synchronous replication makes sure changes are applied aroundthe "
+"cluster before the web request completes. However, synchronous replication "
+"is much slower."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:182
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ClusterName</emphasis> specifies the name of the "
+"cluster that the cache works within. The default cluster name is the the "
+"word \"Tomcat-\" appended by the current JBoss partition name. All the nodes "
+"must use the same cluster name."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:187
+#, no-c-format
+msgid ""
+"The <emphasis role=\"bold\">UseMarshalling</emphasis> and <emphasis role="
+"\"bold\">InactiveOnStartup</emphasis> attributes must have the same value. "
+"They must be <literal>true</literal> if <literal>FIELD</literal> level "
+"session replication is needed (see later). Otherwise, they are default to "
+"<literal>false</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:192
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ClusterConfig</emphasis> configures the underlying "
+"JGroups stack. Please refer to <xref linkend=\"jbosscache-jgroups\"/> for "
+"more information."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:195
+#, no-c-format
+msgid ""
+"<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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:199
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">SyncReplTimeout</emphasis> sets the maximum number "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:207
+#, no-c-format
+msgid "Enabling session replication in your application"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:208
+#, no-c-format
+msgid ""
+"To enable clustering of your web application you must tag it as "
+"distributable in the <literal>web.xml</literal> descriptor. Here's an "
+"example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:210
+#, no-c-format
+msgid ""
+"<?xml version=\"1.0\"?> \n"
+"<web-app xmlns=\"http://java.sun.com/xml/ns/j2ee\"\n"
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \n"
+" xsi:schemaLocation=\"http://java.sun.com/xml/ns/j2ee \n"
+" http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
+"\" \n"
+" version=\"2.4\">\n"
+" <emphasis role=\"bold\"><distributable/></emphasis>\n"
+" <!-- ... -->\n"
+"</web-app>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:211
+#, no-c-format
+msgid ""
+"You can futher configure session replication using the <literal>replication-"
+"config</literal> element in the <literal>jboss-web.xml</literal> file. Here "
+"is an example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:213
+#, no-c-format
+msgid ""
+"<jboss-web>\n"
+" <replication-config>\n"
+" <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-"
+"trigger>\n"
+" <replication-granularity>SESSION</replication-"
+"granularity>\n"
+" <replication-field-batch-mode>true</replication-field-batch-"
+"mode>\n"
+" </replication-config>\n"
+"</jboss-web>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:214
+#, no-c-format
+msgid ""
+"The <literal>replication-trigger</literal> element determines what triggers "
+"a session replication (i.e. when is a session is considered <literal>dirty</"
+"literal> and in need of replication). It has 4 options:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:218
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">SET</emphasis>: With this policy, the session is "
+"considered dirty only when an attribute is set in the session (i.e., "
+"HttpSession.setAttribute() is invoked.) If your application always writes "
+"changed values back into the session, this option will be most optimal in "
+"terms of performance. The downside of SET is that if an object is retrieved "
+"from the session and modified without being written back into the session, "
+"the session manager will not know the attribute is dirty and the change to "
+"that object may not be replicated."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:221
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">SET_AND_GET</emphasis>: With this policy, any "
+"attribute that is get or set will be marked as dirty. If an object is "
+"retrieved from the session and modified without being written back into the "
+"session, the change to that object will be replicated. The downside of "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:224
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: This policy is "
+"similar to the SET_AND_GET policy except that get operationsthat return "
+"attribute values with primitive types do not mark the attribute as dirty. "
+"Primitive system types (i.e., String, Integer, Long, etc.) are immutable, so "
+"there is no reason to mark an attribute with such a type as dirty just "
+"because it has been read. If a get operation returns a value of a non-"
+"primitive type, the session manager has no simple way to know whether the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:227
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ACCESS</emphasis>: This option causes the session to "
+"be marked as dirty whenever it is accessed. Since a the session is accessed "
+"during each HTTP request, it will be replicated with each request. The "
+"purpose of ACCESS is to ensure session last-access timestamps are kept in "
+"sync around the cluster.. Since with the other replication-trigger options "
+"the time stamp may not be updated in other clustering nodes because of no "
+"replication, the session in other nodes may expire before the active node if "
+"the HTTP request does not retrieve or modify any session attributes. When "
+"this option is set, the session timestamps will be synchronized throughout "
+"the cluster nodes. Note that use of this option can have a significant "
+"performance impact, so use it with caution. With the other replication-"
+"trigger options, if a session has gone 80% of its expiration interval "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:230
+#, no-c-format
+msgid ""
+"The <literal>replication-granularity</literal> element controls the size of "
+"the replication units. The supported values are:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:235
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ATTRIBUTE</emphasis>: Replication is only for the "
+"dirty attributes in the session plus some session data, like the last-"
+"accessed timestamp. For sessions that carry large amounts of data, this "
+"option can increase replication performance. However, attributes will be "
+"separately serialized, so if there are any shared references between objects "
+"stored in the attributes, those shared references may be broken on remote "
+"nodes. For example, say a Person object stored under key “husband” has a "
+"reference to an Address, while another Person object stored under key “wife” "
+"has a reference to that same Address object. When the “husband” and “wife” "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:238
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">SESSION</emphasis>: The entire session object is "
+"replicated if any attribute is dirty. The entire session is serialized in "
+"one unit, so shared object references are maintained on remote nodes. This "
+"is the default setting."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:243
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">FIELD</emphasis>: Replication is only for individual "
+"changed data fields inside session attribute objects. Shared object "
+"references will be preserved across the cluster. Potentially most "
+"performant, but requires changes to your application (this will be discussed "
+"later)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:246
+#, no-c-format
+msgid ""
+"The <literal>replication-field-batch-mode</literal> element indicates "
+"whether you want all replication messages associated with a request to be "
+"batched into one message. Only applicable if replication-granularity is "
+"FIELD. Default is <literal>true</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:247
+#, no-c-format
+msgid ""
+"If your sessions are generally small, SESSION is the better policy. If your "
+"session is larger and some parts are infrequently accessed, ATTRIBUTE "
+"replication will be more effective. If your application has very big data "
+"objects in session attributes and only fields in those objects are "
+"frequently modified, the FIELD policy would be the best. In the next "
+"section, we will discuss exactly how the FIELD level replication works."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:259
+#, no-c-format
+msgid "Using FIELD level replication"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:260
+#, no-c-format
+msgid ""
+"FIELD-level replication only replicates modified data fields inside objects "
+"stored in the session. Its use could potentially drastically reduce the data "
+"traffic between clustered nodes, and hence improve the performance of the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:262
+#, no-c-format
+msgid ""
+"The first step in doing this is to identify the classes that need to be "
+"prepared. This is done via annotations. For example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:266
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@org.jboss.cache.aop.AopMarker\n"
+"public class Address \n"
+"{\n"
+"...\n"
+"}]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:268
+#, no-c-format
+msgid ""
+"If you annotate a class with InstanceAopMarker instead, then all of its "
+"subclasses will be automatically annotated as well. Similarly, you can "
+"annotate an interface with InstanceofAopMarker and all of its implementing "
+"classes will be annotated. For example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:271
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@org.jboss.cache.aop.InstanceOfAopMarker\n"
+"public class Person \n"
+"{\n"
+"...\n"
+"}\n"
+"then when you have a sub-class like\n"
+"public class Student extends Person\n"
+"{\n"
+"...\n"
+"}\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:273
+#, no-c-format
+msgid ""
+"There will be no need to annotate <literal>Student</literal>. It will be "
+"annotated automatically because it is a sub-class of <literal>Person</"
+"literal>. Jboss AS 4.2 requires JDK 5 at runtime, but some users may still "
+"need to build their projects using JDK 1.4. In this case, annotating classes "
+"can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:278
+#, no-c-format
+msgid ""
+"/*\n"
+" * My usual comments here first.\n"
+" * @@org.jboss.web.tomcat.tc5.session.AopMarker\n"
+" */\n"
+"public class Address \n"
+"{\n"
+"...\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:281
+#, no-c-format
+msgid "The anologue for <literal>@InstanceAopMarker</literal> is:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:283
+#, no-c-format
+msgid ""
+"/*\n"
+" *\n"
+" * @@org.jboss.web.tomcat.tc5.session.InstanceOfAopMarker\n"
+" */\n"
+"public class Person \n"
+"{\n"
+"...\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:287
+#, no-c-format
+msgid ""
+"Once you have annotated your classes, you will need to perform a pre-"
+"processing step to bytecode enhance your classes for use by TreeCacheAop. "
+"You need to use the JBoss AOP pre-compiler <literal>annotationc</literal> "
+"and post-compiler <literal>aopc</literal> to process the above source code "
+"before and after they are compiled by the Java compiler. The annotationc "
+"step is only need if the JDK 1.4 style annotations are used; if JDK 5 "
+"annotations are used it is not necessary. Here is an example on how to "
+"invoke those commands from command line."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:291
+#, no-c-format
+msgid ""
+"$ annotationc [classpath] [source files or directories]\n"
+"$ javac -cp [classpath] [source files or directories]\n"
+"$ aopc [classpath] [class files or directories]"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:293
+#, no-c-format
+msgid ""
+"Please see the JBoss AOP documentation for the usage of the pre- and post-"
+"compiler. The JBoss AOP project also provides easy to use ANT tasks to help "
+"integrate those steps into your application build process."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:297
+#, no-c-format
+msgid ""
+"You can see a complete example on how to build, deploy, and validate a FIELD-"
+"level replicated web application from this page: <ulink url=\"http://wiki."
+"jboss.org/wiki/Wiki.jsp?page=Http_session_field_level_example\"></ulink>. "
+"The example bundles the pre- and post-compile tools so you do not need to "
+"download JBoss AOP separately."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:301
+#, no-c-format
+msgid ""
+"When you deploy the web application into JBoss AS, make sure that the "
+"following configurations are correct:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:305
+#, no-c-format
+msgid ""
+"In the server's <literal>deploy/jboss-web-cluster.sar/META-INF/jboss-service."
+"xml</literal> file, the <literal>inactiveOnStartup</literal> and "
+"<literal>useMarshalling</literal> attributes must both be <literal>true</"
+"literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:310
+#, no-c-format
+msgid ""
+"In the application's <literal>jboss-web.xml</literal> file, the "
+"<literal>replication-granularity</literal> attribute must be <literal>FIELD</"
+"literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:315
+#, no-c-format
+msgid ""
+"Finally, let's see an example on how to use FIELD-level replication on those "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:318
+#, no-c-format
+msgid ""
+"// Do this only once. So this can be in init(), e.g.\n"
+"if(firstTime)\n"
+"{\n"
+" Person joe = new Person(\"Joe\", 40);\n"
+" Person mary = new Person(\"Mary\", 30);\n"
+" Address addr = new Address();\n"
+" addr.setZip(94086);\n"
+"\n"
+" joe.setAddress(addr);\n"
+" mary.setAddress(addr); // joe and mary share the same address!\n"
+"\n"
+" session.setAttribute(\"joe\", joe); // that's it.\n"
+" session.setAttribute(\"mary\", mary); // that's it.\n"
+"}\n"
+"\n"
+"Person mary = (Person)session.getAttribute(\"mary\");\n"
+"mary.getAddress().setZip(95123); // this will update and replicate the zip "
+"code."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:319
+#, no-c-format
+msgid ""
+"Besides plain objects, you can also use regular Java collections of those "
+"objects as session attributes. JBoss cache automatically figures out how to "
+"handle those collections and replicate field changes in their member objects."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:324
+#, no-c-format
+msgid "Monitoring session replication"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:325
+#, no-c-format
+msgid ""
+"If you have deployed and accessed your application, go to the <literal>jboss."
+"cache:service=TomcatClusteringCache</literal> MBean and invoke the "
+"<literal>printDetails</literal> operation. You should see output resembling "
+"the following."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:328
+#, no-c-format
+msgid ""
+"/JSESSION\n"
+"\n"
+"/localhost\n"
+"\n"
+"/quote\n"
+"\n"
+"/FB04767C454BAB3B2E462A27CB571330\n"
+"VERSION: 6\n"
+"FB04767C454BAB3B2E462A27CB571330: org.jboss.invocation."
+"MarshalledValue at 1f13a81c\n"
+"\n"
+"/AxCI8Ovt5VQTfNyYy9Bomw**\n"
+"VERSION: 4\n"
+"AxCI8Ovt5VQTfNyYy9Bomw**: org.jboss.invocation.MarshalledValue at e076e4c8"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:330
+#, no-c-format
+msgid ""
+"This output shows two separate web sessions, in one application named "
+"<emphasis>quote</emphasis>, that are being shared via JBossCache. This "
+"example uses a <literal>replication-granularity</literal> of "
+"<literal>session</literal>. Had <literal>ATTRIBUTE</literal> level "
+"replication been used, there would be additional entries showing each "
+"replicated session attribute. In either case, the replicated values are "
+"stored in an opaque <literal>MarshelledValue</literal> container. There "
+"aren't currently any tools that allow you to inspect the contents of the "
+"replicated session values. If you do not see any output, either the "
+"application was not correctly marked as <literal>distributable</literal> or "
+"you haven't accessed a part of application that places values in the HTTP "
+"session. The <literal>org.jboss.cache</literal> and <literal>org.jboss.web</"
+"literal> logging categories provide additional insight into session "
+"replication useful for debugging purposes."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:338
+#, no-c-format
+msgid "Using Clustered Single Sign On"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:340
+#, no-c-format
+msgid ""
+"JBoss supports clustered single sign-on, allowing a user to authenticate to "
+"one web application on a JBoss server and to be recognized on all web "
+"applications, on that same machine or on another node in the cluster, that "
+"are deployed on the same virtual host. Authentication replication is handled "
+"by the same JBoss Cache Mbean that is used by the HTTP session replication "
+"service. Although session replication does not need to be explicitly enabled "
+"for the applications in question, the <literal>jboss-web-cluster.sar</"
+"literal> file needs to be deployed."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:342
+#, no-c-format
+msgid ""
+"To enable single sign-on, you must add the <literal>ClusteredSingleSignOn</"
+"literal> valve to the appropriate <literal>Host</literal> elements of the "
+"tomcat <literal>server.xml</literal> file. The valve configuration is shown "
+"here:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:345
+#, no-c-format
+msgid ""
+"<Valve className=\"org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn\" /"
+">"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:348
+#, no-c-format
+msgid "Clustered Singleton Services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:349
+#, no-c-format
+msgid ""
+"A clustered singleton service (also known as an HA singleton) is a service "
+"that is deployed on multiple nodes in a cluster, but is providing its "
+"service on only one of the nodes. The node running the singleton service is "
+"typically called the master node. When the master fails or is shut down, "
+"another master is selected from the remaining nodes and the service is "
+"restarted on the new master. Thus, other than a brief interval when one "
+"master has stopped and another has yet to take over, the service is always "
+"being provided by one but only one node."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:352
+#, no-c-format
+msgid "Topology after the Master Node fails"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:360
+#, no-c-format
+msgid ""
+"The JBoss Application Server (AS) provides support for a number of "
+"strategies for helping you deploy clustered singleton services. In this "
+"section we will explore the different strategies. All of the strategies are "
+"built on top of the HAPartition service described in the introduction. They "
+"rely on the <literal>HAPartition</literal> to provide notifications when "
+"different nodes in the cluster start and stop; based on those notifications "
+"each node in the cluster can independently (but consistently) determine if "
+"it is now the master node and needs to begin providing a service."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:365
+#, no-c-format
+msgid "HASingletonDeployer service"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:366
+#, no-c-format
+msgid ""
+"The simplest and most commonly used strategy for deploying an HA singleton "
+"is to take an ordinary deployment (war, ear, jar, whatever you would "
+"normally put in deploy) and deploy it in the <literal>$JBOSS_HOME/server/all/"
+"deploy-hasingleton</literal> directory instead of in <literal>deploy</"
+"literal>. The <literal>deploy-hasingleton</literal> directory does not lie "
+"under deploy or farm, so its contents are not automatically deployed when an "
+"AS instance starts. Instead, deploying the contents of this directory is the "
+"responsibility of a special service, the <literal>jboss.ha:"
+"service=HASingletonDeployer</literal> MBean (which itself is deployed via "
+"the deploy/deploy-hasingleton-service.xml file.) The HASingletonDeployer "
+"service is itself an HA Singleton, one whose provided service when it "
+"becomes master is to deploy the contents of deploy-hasingleton and whose "
+"service when it stops being the master (typically at server shutdown) is to "
+"undeploy the contents of <literal>deploy-hasingleton</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:369
+#, no-c-format
+msgid ""
+"So, by placing your deployments in <literal>deploy-hasingleton</literal> you "
+"know that they will be deployed only on the master node in the cluster. If "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:372
+#, no-c-format
+msgid ""
+"Using deploy-hasingleton is very simple, but it does have two drawbacks:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:376
+#, no-c-format
+msgid ""
+"There is no hot-deployment feature for services in <literal>deploy-"
+"hasingleton</literal>. Redeploying a service that has been deployed to "
+"<literal>deploy-hasingleton</literal> requires a server restart."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:381
+#, no-c-format
+msgid ""
+"If the master node fails and another node takes over as master, your "
+"singleton service needs to go through the entire deployment process before "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:393
+#, no-c-format
+msgid "Mbean deployments using HASingletonController"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:394
+#, no-c-format
+msgid ""
+"If your service is an Mbean (i.e., not a J2EE deployment like an ear or war "
+"or jar), you can deploy it along with a service called an "
+"HASingletonController in order to turn it into an HA singleton. It is the "
+"job of the HASingletonController to work with the HAPartition service to "
+"monitor the cluster and determine if it is now the master node for its "
+"service. If it determines it has become the master node, it invokes a method "
+"on your service telling it to begin providing service. If it determines it "
+"is no longer the master node, it invokes a method on your service telling it "
+"to stop providing service. Let's walk through an illustration."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:397
+#, no-c-format
+msgid ""
+"First, we have an MBean service that we want to make an HA singleton. The "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:400
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"public class HASingletonExample\n"
+"implements HASingletonExampleMBean { \n"
+" \n"
+"private boolean isMasterNode = false; \n"
+" \n"
+"public void startSingleton() { \n"
+"isMasterNode = true; \n"
+"} \n"
+". \n"
+"public boolean isMasterNode() { \n"
+"return isMasterNode; \n"
+" } \n"
+" \n"
+" public void stopSingleton() { \n"
+" isMasterNode = false; \n"
+" } \n"
+"} ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:402
+#, no-c-format
+msgid ""
+"We used “startSingleton” and “stopSingleton” in the above example, but you "
+"could name the methods anything."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:405
+#, no-c-format
+msgid ""
+"Next, we deploy our service, along with an HASingletonController to control "
+"it, most likely packaged in a .sar file, with the following <literal>META-"
+"INF/jboss-service.xml</literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:408
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+" <server> \n"
+" <!-- This MBean is an example of a clustered singleton --> \n"
+" <mbean code=\"org.jboss.ha.examples.HASingletonExample\" \n"
+" name=“jboss:service=HASingletonExample\"/> \n"
+" \n"
+" <!-- This HASingletonController manages the cluster Singleton --> \n"
+" <mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+" name=\"jboss:service=ExampleHASingletonController\"> \n"
+" \n"
+" <!-- Inject a ref to the HAPartition -->\n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-"
+"type=\"attribute\">\n"
+" jboss:service=${jboss.partition.name:"
+"DefaultPartition}\n"
+" </depends> \n"
+" <!-- Inject a ref to the service being controlled -->\n"
+" <depends optional-attribute-name=\"TargetName\">\n"
+" jboss:service=HASingletonExample\n"
+" </depends>\n"
+" <!-- Methods to invoke when become master / stop being "
+"master -->\n"
+" <attribute name=\"TargetStartMethod\">startSingleton</"
+"attribute> \n"
+" <attribute name=\"TargetStopMethod\">stopSingleton</"
+"attribute> \n"
+" </mbean> \n"
+"</server> ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:410
+#, no-c-format
+msgid "Voila! A clustered singleton service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:412
+#, no-c-format
+msgid ""
+"The obvious downside to this approach is it only works for MBeans. Upsides "
+"are that the above example can be placed in <literal>deploy</literal> or "
+"<literal>farm</literal> and thus can be hot deployed and farmed deployed. "
+"Also, if our example service had complex, time-consuming startup "
+"requirements, those could potentially be implemented in create() or start() "
+"methods. JBoss will invoke create() and start() as soon as the service is "
+"deployed; it doesn't wait until the node becomes the master node. So, the "
+"service could be primed and ready to go, just waiting for the controller to "
+"implement startSingleton() at which point it can immediately provide service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:415
+#, no-c-format
+msgid ""
+"The jboss.ha:service=HASingletonDeployer service discussed above is itself "
+"an interesting example of using an HASingletonController. Here is its "
+"deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
+"service.xml</literal> file):"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:418
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+"name=\"jboss.ha:service=HASingletonDeployer\"> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-type=\"attribute"
+"\">\n"
+" jboss:service=${jboss.partition.name:DefaultPartition}\n"
+" </depends> \n"
+" <depends optional-attributeame=\"TargetName\">\n"
+" jboss.system:service=MainDeployer\n"
+" </depends> \n"
+" <attribute name=\"TargetStartMethod\">deploy</attribute> \n"
+" <attribute name=\"TargetStartMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+" <attribute name=\"TargetStopMethod\">undeploy</attribute> \n"
+" <attribute name=\"TargetStopMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+"</mbean> ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:420
+#, no-c-format
+msgid ""
+"A few interesting things here. First the service being controlled is the "
+"<literal>MainDeployer</literal> service, which is the core deployment "
+"service in JBoss. That is, it's a service that wasn't written with an intent "
+"that it be controlled by an <literal>HASingletonController</literal>. But it "
+"still works! Second, the target start and stop methods are “deploy” and "
+"“undeploy”. No requirement that they have particular names, or even that "
+"they logically have “start” and “stop” functionality. Here the functionality "
+"of the invoked methods is more like “do” and “undo”. Finally, note the "
+"“<literal>TargetStart(Stop)MethodArgument</literal>” attributes. Your "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:428
+#, no-c-format
+msgid "HASingleton deployments using a Barrier"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:429
+#, no-c-format
+msgid ""
+"Services deployed normally inside deploy or farm that want to be started/"
+"stopped whenever the content of deploy-hasingleton gets deployed/undeployed, "
+"(i.e., whenever the current node becomes the master), need only specify a "
+"dependency on the Barrier mbean:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_HTTP.xml:431
+#, no-c-format
+msgid ""
+"<![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</"
+"depends>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:433
+#, no-c-format
+msgid ""
+"The way it works is that a BarrierController is deployed along with the "
+"jboss.ha:service=HASingletonDeployer MBean and listens for JMX notifications "
+"from it. A BarrierController is a relatively simple Mbean that can subscribe "
+"to receive any JMX notification in the system. It uses the received "
+"notifications to control the lifecycle of a dynamically created Mbean called "
+"the Barrier.The Barrier is instantiated, registered and brought to the "
+"CREATE state when the BarrierController is deployed. After that, the "
+"BarrierController starts and stops the Barrier when matching JMX "
+"notifications are received. Thus, other services need only depend on the "
+"Barrier MBean using the usual <depends> tag, and they will be started "
+"and stopped in tandem with the Barrier. When the BarrierController is "
+"undeployed the Barrier is destroyed too."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:437
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:440
+#, no-c-format
+msgid ""
+"On the other hand, the barrier-dependent service will be instantiated/"
+"created (i.e., any create() method invoked) on all nodes, but only started "
+"on the master node. This is different with the deploy-hasingleton approach "
+"that will only deploy (instantiate/create/start) the contents of the deploy-"
+"hasingleton directory on one of the nodes."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:444
+#, no-c-format
+msgid ""
+"So services depending on the barrier will need to make sure they do minimal "
+"or no work inside their create() step, rather they should use start() to do "
+"the work."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:448
+#, no-c-format
+msgid ""
+"The Barrier controls the start/stop of dependent services, but not their "
+"destruction, which happens only when the <literal>BarrierController</"
+"literal> is itself destroyed/undeployed. Thus using the <literal>Barrier</"
+"literal> to control services that need to be \"destroyed\" as part of their "
+"normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
+"literal>) will not have the desired effect."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_HTTP.xml:457
+#, no-c-format
+msgid "Determining the master node"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:458
+#, no-c-format
+msgid ""
+"The various clustered singleton management strategies all depend on the fact "
+"that each node in the cluster can independently react to changes in cluster "
+"membership and correctly decide whether it is now the “master node”. How is "
+"this done?"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:461
+#, no-c-format
+msgid ""
+"Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple. For "
+"each member of the cluster, the HAPartition mbean maintains an attribute "
+"called the CurrentView, which is basically an ordered list of the current "
+"members of the cluster. As nodes join and leave the cluster, JGroups ensures "
+"that each surviving member of the cluster gets an updated view. You can see "
+"the current view by going into the JMX console, and looking at the "
+"CurrentView attribute in the <literal>jboss:service=DefaultPartition</"
+"literal> mbean. Every member of the cluster will have the same view, with "
+"the members in the same order."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:464
+#, no-c-format
+msgid ""
+"Let's say, for example, that we have a 4 node cluster, nodes A through D, "
+"and the current view can be expressed as {A, B, C, D}. Generally speaking, "
+"the order of nodes in the view will reflect the order in which they joined "
+"the cluster (although this is not always the case, and should not be assumed "
+"to be the case.)"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:467
+#, no-c-format
+msgid ""
+"To further our example, let's say there is a singleton service (i.e., an "
+"<literal>HASingletonController</literal>) named Foo that's deployed around "
+"the cluster, except, for whatever reason, on B. The <literal>HAPartition</"
+"literal> service maintains across the cluster a registry of what services "
+"are deployed where, in view order. So, on every node in the cluster, the "
+"<literal>HAPartition</literal> service knows that the view with respect to "
+"the Foo service is {A, C, D} (no B)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:471
+#, no-c-format
+msgid ""
+"Whenever there is a change in the cluster topology of the Foo service, the "
+"<literal>HAPartition</literal> service invokes a callback on Foo notifying "
+"it of the new topology. So, for example, when Foo started on D, the Foo "
+"service running on A, C and D all got callbacks telling them the new view "
+"for Foo was {A, C, D}. That callback gives each node enough information to "
+"independently decide if it is now the master. The Foo service on each node "
+"does this by checking if they are the first member of the view – if they "
+"are, they are the master; if not, they're not. Simple as that."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_HTTP.xml:475
+#, no-c-format
+msgid ""
+"If A were to fail or shutdown, Foo on C and D would get a callback with a "
+"new view for Foo of {C, D}. C would then become the master. If A restarted, "
+"A, C and D would get a callback with a new view for Foo of {C, D, A}. C "
+"would remain the master – there's nothing magic about A that would cause it "
+"to become the master again just because it was before."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Intro.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Intro.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_Intro.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,761 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:5
+#, no-c-format
+msgid "Clustering"
+msgstr ""
+
+#. Tag: subtitle
+#: Clustering_Guide_Intro.xml:6
+#, no-c-format
+msgid "High Availability Enterprise Services via JBoss Clusters"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:9
+#, no-c-format
+msgid "Introduction"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:10
+#, no-c-format
+msgid ""
+"Clustering allows us to run an application on several parallel servers (a.k."
+"a cluster nodes) while providing a single view to application clients. Load "
+"is distributed across different servers, and even if one or more of the "
+"servers fails, the application is still accessible via the surviving cluster "
+"nodes. Clustering is crucial for scalable enterprise applications, as you "
+"can improve performance by simply adding more nodes to the cluster. "
+"Clustering is crucial for highly available enterprise applications, as it is "
+"the clustering infrastructure that supports the redundancy needed for high "
+"availability."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:14
+#, no-c-format
+msgid ""
+"The JBoss Application Server (AS) comes with clustering support out of the "
+"box. The simplest way to start a JBoss server cluster is to start several "
+"JBoss instances on the same local network, using the <literal>run -c all</"
+"literal> command for each instance. Those server instances, all started in "
+"the <literal>all</literal> configuration, detect each other and "
+"automatically form a cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:17
+#, no-c-format
+msgid ""
+"In the first section of this chapter, we discuss basic concepts behind "
+"JBoss's clustering services. It is important that you understand these "
+"concepts before reading the rest of the chapter. Clustering configurations "
+"for specific types of applications are covered after this section."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:23
+#, no-c-format
+msgid "Cluster Definition"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:24
+#, no-c-format
+msgid ""
+"A cluster is a set of nodes that communicate with each other and work toward "
+"a common goal. In a JBoss Application Server cluster (also known as a "
+"“partition”), a node is an JBoss Application Server instance. Communication "
+"between the nodes is handled by the JGroups group communication library, "
+"with a JGroups Channel providing the core functionality of tracking who is "
+"in the cluster and reliably exchanging messages between the cluster members. "
+"JGroups channels with the same configuration and name have the ability to "
+"dynamically discover each other and form a group. This is why simply "
+"executing “run -c all” on two AS instances on the same network is enough for "
+"them to form a cluster – each AS starts a Channel (actually, several) with "
+"the same default configuration, so they dynamically discover each other and "
+"form a cluster. Nodes can be dynamically added to or removed from clusters "
+"at any time, simply by starting or stopping a Channel with a configuration "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:29
+#, no-c-format
+msgid ""
+"On the same AS instance, different services can create their own Channel. In "
+"a default 4.2.x AS, four different services create channels – the web "
+"session replication service, the EJB3 SFSB replication service, the EJB3 "
+"entity caching service, and a core general purpose clustering service known "
+"as HAPartition. In order to differentiate these channels, each must have a "
+"unique name, and its configuration must match its peers yet differ from the "
+"other channels."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:32
+#, no-c-format
+msgid ""
+"So, if you go to two AS 4.2.x instances and execute <literal>run -c all</"
+"literal>, the channels will discover each other and you'll have a conceptual "
+"<literal>cluster</literal>. It's easy to think of this as a two node "
+"cluster, but it's important to understand that you really have 4 channels, "
+"and hence 4 two node clusters."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:36
+#, no-c-format
+msgid ""
+"On the same network, even for the same service, we may have different "
+"clusters. <xref linkend=\"clustering-Partition.fig\"/> shows an example "
+"network of JBoss server instances divided into three clusters, with the "
+"third cluster only having one node. This sort of topology can be set up "
+"simply by configuring the AS instances such that within a set of nodes meant "
+"to form a cluster the Channel configurations and names match while they "
+"differ from any other channels on the same network."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:38
+#, no-c-format
+msgid "Clusters and server nodes"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:46
+#, no-c-format
+msgid ""
+"The section on “JGroups Configuration” and on “Isolating JGroups Channels” "
+"covers in detail how to configure Channels such that desired peers find each "
+"other and unwanted peers do not. As mentioned above, by default JBoss AS "
+"uses four separate JGroups Channels. These can be divided into two broad "
+"categories: the Channel used by the general purpose HAPartition service, and "
+"three Channels created by JBoss Cache for special purpose caching and "
+"cluster wide state replication."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:50
+#, no-c-format
+msgid "HAPartition"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:52
+#, no-c-format
+msgid ""
+"HAPartition is a general purpose service used for a variety of tasks in AS "
+"clustering. At its core, it is an abstraction built on top of a JGroups "
+"Channel that provides support for making/receiving RPC invocations on/from "
+"one or more cluster members. HAPartition also supports a distributed "
+"registry of which clustering services are running on which cluster members. "
+"It provides notifications to interested listeners when the cluster "
+"membership changes or the clustered service registry changes. HAPartition "
+"forms the core of many of the clustering services we'll be discussing in the "
+"rest of this guide, including smart client-side clustered proxies, EJB 2 "
+"SFSB replication and entity cache management, farming, HA-JNDI and HA "
+"singletons."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:57
+#, no-c-format
+msgid ""
+"The following example shows the <literal>HAPartition</literal> MBean "
+"definition packaged with the standard JBoss AS distribution. So, if you "
+"simply start JBoss servers with their default clustering settings on a local "
+"network, you would get a default cluster named <literal>DefaultPartition</"
+"literal> that includes all server instances as its nodes."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Intro.xml:61
+#, no-c-format
+msgid ""
+"<mbean code=\"org.jboss.ha.framework.server.ClusterPartition\"\n"
+" name=\"jboss:service=DefaultPartition\">\n"
+" \n"
+" <! -- Name of the partition being built -->\n"
+" <attribute name=\"PartitionName\">\n"
+" ${jboss.partition.name:DefaultPartition}\n"
+" </attribute>\n"
+"\n"
+" <! -- The address used to determine the node name -->\n"
+" <attribute name=\"NodeAddress\">${jboss.bind.address}</"
+"attribute>\n"
+"\n"
+" <! -- Determine if deadlock detection is enabled -->\n"
+" <attribute name=\"DeadlockDetection\">False</attribute>\n"
+" \n"
+" <! -- Max time (in ms) to wait for state transfer to complete. \n"
+" Increase for large states -->\n"
+" <attribute name=\"StateTransferTimeout\">30000</attribute>\n"
+"\n"
+" <! -- The JGroups protocol configuration -->\n"
+" <attribute name=\"PartitionConfig\">\n"
+" ... ...\n"
+" </attribute>\n"
+"</mbean>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:62
+#, no-c-format
+msgid ""
+"Here, we omitted the detailed JGroups protocol configuration for this "
+"channel. JGroups handles the underlying peer-to-peer communication between "
+"nodes, and its configuration is discussed in <xref linkend=\"jbosscache-"
+"jgroups\"/>. The following list shows the available configuration attributes "
+"in the <literal>HAPartition</literal> MBean."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:67
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">PartitionName</emphasis> is an optional attribute to "
+"specify the name of the cluster. Its default value is "
+"<literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. "
+"--partition) command line switch to set this value at JBoss startup."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:71
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">NodeAddress</emphasis> is an optional attribute used "
+"to help generate a unique name for this node."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:74
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">DeadlockDetection</emphasis> is an optional boolean "
+"attribute that tells JGroups to run message deadlock detection algorithms "
+"with every request. Its default value is <literal>false</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:79
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">StateTransferTimeout</emphasis> is an optional "
+"attribute to specify the timeout for state replication across the cluster "
+"(in milliseconds). State replication refers to the process of obtaining "
+"initial application state from other already-running cluster members at "
+"service startup. Its default value is <literal>30000</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:82
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">PartitionConfig</emphasis> is an element to specify "
+"JGroup configuration options for this cluster (see <xref linkend="
+"\"jbosscache-jgroups\"/>)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:86
+#, no-c-format
+msgid ""
+"In order for nodes to form a cluster, they must have the exact same "
+"<literal>PartitionName</literal> and the <literal>ParitionConfig</literal> "
+"elements. Changes in either element on some but not all nodes would cause "
+"the cluster to split."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:89
+#, no-c-format
+msgid ""
+"You can view the current cluster information by pointing your browser to the "
+"JMX console of any JBoss instance in the cluster (i.e., <literal>http://"
+"hostname:8080/jmx-console/</literal>) and then clicking on the "
+"<literal>jboss:service=DefaultPartition</literal> MBean (change the MBean "
+"name to reflect your partitionr name if you use the -g startup switch). A "
+"list of IP addresses for the current cluster members is shown in the "
+"CurrentView field."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:93
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:94
+#, no-c-format
+msgid ""
+"While it is technically possible to put a JBoss server instance into "
+"multiple HAPartitions at the same time, this practice is generally not "
+"recommended, as it increases management complexity."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:100
+#, no-c-format
+msgid "JBoss Cache channels"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:101
+#, no-c-format
+msgid ""
+"JBoss Cache is a fully featured distributed cache framework that can be used "
+"in any application server environment or standalone. JBoss AS integrates "
+"JBoss Cache to provide cache services for HTTP sessions, EJB 3.0 session "
+"beans, and EJB 3.0 entity beans. Each of these cache services is defined in "
+"a separate Mbean, and each cache creates its own JGroups Channel. We will "
+"cover those MBeans when we discuss specific services in the next several "
+"sections."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:106
+#, no-c-format
+msgid "Service Architectures"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:107
+#, no-c-format
+msgid ""
+"The clustering topography defined by the <literal>HAPartition</literal> "
+"MBean on each node is of great importance to system administrators. But for "
+"most application developers, you are probably more concerned about the "
+"cluster architecture from a client application's point of view. Two basic "
+"clustering architectures are used with JBoss AS: client-side interceptors (a."
+"k.a smart proxies or stubs) and external load balancers. Which architecture "
+"your application will use will depend on what type of client you have."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:113 Clustering_Guide_Intro.xml:159
+#, no-c-format
+msgid "Client-side interceptor architecture"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:114
+#, no-c-format
+msgid ""
+"Most remote services provided by the JBoss application server, including "
+"JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain (e.g., "
+"to look up and download) a stub (or proxy) object. The stub object is "
+"generated by the server and it implements the business interface of the "
+"service. The client then makes local method calls against the stub object. "
+"The stub automatically routes the call across the network and where it is "
+"invoked against service objects managed in the server. In a clustering "
+"environment, the server-generated stub object includes an interceptor that "
+"understands how to route calls to multiple nodes in the cluster. The stub "
+"object figures out how to find the appropriate server node, marshal call "
+"parameters, un-marshall call results, and return the result to the caller "
+"client."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:119
+#, no-c-format
+msgid ""
+"The stub interceptors maintain up-to-date knowledge about the cluster. For "
+"instance, they know the IP addresses of all available server nodes, the "
+"algorithm to distribute load across nodes (see next section), and how to "
+"failover the request if the target node not available. As part of handling "
+"each service request, if the cluster topology has changed the server node "
+"updates the stub interceptor with the latest changes in the cluster. For "
+"instance, if a node drops out of the cluster, each of client stub "
+"interceptor is updated with the new configuration the next time it connects "
+"to any active node in the cluster. All the manipulations done by the service "
+"stub are transparent to the client application. The client-side interceptor "
+"clustering architecture is illustrated in <xref linkend=\"clustering-"
+"InterceptorArch.fig\"/>."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:122
+#, no-c-format
+msgid "The client-side interceptor (proxy) architecture for clustering"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:130
+#, no-c-format
+msgid ""
+"describes how to enable the client proxy to handle the entire cluster "
+"restart."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:135
+#, no-c-format
+msgid "Load balancer"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:136
+#, no-c-format
+msgid ""
+"Other JBoss services, in particular the HTTP-based services, do not require "
+"the client to download anything. The client (e.g., a web browser) sends in "
+"requests and receives responses directly over the wire according to certain "
+"communication protocols (e.g., the HTTP protocol). In this case, an external "
+"load balancer is required to process all requests and dispatch them to "
+"server nodes in the cluster. The client only needs to know about how to "
+"contact the load balancer; it has no knowledge of the JBoss AS instances "
+"behind the load balancer. The load balancer is logically part of the "
+"cluster, but we refer to it as “external” because it is not running in the "
+"same process as either the client or any of the JBoss AS instances. It can "
+"be implemented either in software or hardware. There are many vendors of "
+"hardware load balancers; the mod_jk Apache module is an excellent example of "
+"a software load balancer. An external load balancer implements its own "
+"mechanism for understanding the cluster configuration and provides its own "
+"load balancing and failover policies. The external load balancer clustering "
+"architecture is illustrated in <xref linkend=\"clustering-BalancerArch.fig\"/"
+">."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:140
+#, no-c-format
+msgid "The external load balancer architecture for clustering"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:147
+#, no-c-format
+msgid ""
+"A potential problem with an external load balancer architecture is that the "
+"load balancer itself may be a single point of failure. It needs to be "
+"monitored closely to ensure high availability of the entire cluster's "
+"services."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:154
+#, no-c-format
+msgid "Load-Balancing Policies"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:155
+#, no-c-format
+msgid ""
+"Both the JBoss client-side interceptor (stub) and load balancer use load "
+"balancing policies to determine which server node to which node a new "
+"request should be sent. In this section, let's go over the load balancing "
+"policies available in JBoss AS."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:160
+#, no-c-format
+msgid ""
+"In JBoss 4.2.2, the following load balancing options are available when the "
+"client-side interceptor architecture is used. The client-side stub maintains "
+"a list of all nodes providing the target service; the job of the load "
+"balance policy is to pick a node from this list for each request."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:165
+#, no-c-format
+msgid ""
+"Round-Robin (<literal>org.jboss.ha.framework.interfaces.RoundRobin</"
+"literal>): each call is dispatched to a new node, proceeding sequentially "
+"through the list of nodes. The first target node is randomly selected from "
+"the list."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:171
+#, no-c-format
+msgid ""
+"Random-Robin (<literal>org.jboss.ha.framework.interfaces.RandomRobin</"
+"literal>): for each call the target node is randomly selected from the list."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:176
+#, no-c-format
+msgid ""
+"First Available (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</"
+"literal>): one of the available target nodes is elected as the main target "
+"and is thereafter used for every call; this elected member is randomly "
+"chosen from the list of members in the cluster. When the list of target "
+"nodes changes (because a node starts or dies), the policy will choose a new "
+"target node unless the currently elected node is still available. Each "
+"client-side stub elects its own target node independently of the other "
+"stubs, so if a particular client downloads two stubs for the same target "
+"service (e.g., an EJB), each stub will independently pick its target. This "
+"is an example of a policy that provides “session affinity” or “sticky "
+"sessions”, since the target node does not change once established."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:183
+#, no-c-format
+msgid ""
+"First Available Identical All Proxies (<literal>org.jboss.ha.framework."
+"interfaces.FirstAvailableIdenticalAllProxies</literal>): has the same "
+"behaviour as the \"First Available\" policy but the elected target node is "
+"shared by all stubs in the same client-side VM that are associated with the "
+"same target service. So if a particular client downloads two stubs for the "
+"same target service (e.g. an EJB), each stub will use the same target."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:189
+#, no-c-format
+msgid ""
+"Each of the above is an implementation of the org.jboss.ha.framework."
+"interfaces.LoadBalancePolicy interface; users are free to write their own "
+"implementation of this simple interface if they need some special behavior. "
+"In later sections we'll see how to configure the load balance policies used "
+"by different services."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:193
+#, no-c-format
+msgid "External load balancer architecture"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:195
+#, no-c-format
+msgid ""
+"As noted above, an external load balancer provides its own load balancing "
+"capabilities. What capabilities are supported depends on the provider of the "
+"load balancer. The only JBoss requirement is that the load balancer support "
+"“session affinitiy” (a.k.a. “sticky sessions”). With session affinitiy "
+"enabled, once the load balancer routes a request from a client to node A and "
+"the server initiates a session, all future requests associated with that "
+"session must be routed to node A, so long as node A is available."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:205
+#, no-c-format
+msgid "Farming Deployment"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:206
+#, no-c-format
+msgid ""
+"The easiest way to deploy an application into the cluster is to use the "
+"farming service. That is to hot-deploy the application archive file (e.g., "
+"the EAR, WAR or SAR file) in the <code>all/farm/</code> directory of any of "
+"the cluster members and the application will be automatically duplicated "
+"across all nodes in the same cluster. If node joins the cluster later, it "
+"will pull in all farm deployed applications in the cluster and deploy them "
+"locally at start-up time. If you delete the application from one of the "
+"running cluster server node's <literal>farm/</literal> folder, the "
+"application will be undeployed locally and then removed from all other "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:216
+#, no-c-format
+msgid ""
+"Currently, due to an implementation weakness, the farm deployment service "
+"only works for 1) archives located in the farm/ directory of the first node "
+"to join the cluster or 2) hot-deployed archives. If you first put a new "
+"application in the farm/ directory and then start the server to have it join "
+"an already running cluster, the application will not be pushed across the "
+"cluster or deployed. This is because the farm service does not know whether "
+"the application really represents a new deployment or represents an old "
+"deployment that was removed from the rest of the cluster while the newly "
+"starting node was off-line. We are working to resolve this issue."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:219
+#, no-c-format
+msgid ""
+"You can only put zipped archive files, not exploded directories, in the farm "
+"directory. If exploded directories are placed in farm the directory contents "
+"will be replicated around the cluster piecemeal, and it is very likely that "
+"remote nodes will begin trying to deploy things before all the pieces have "
+"arrived, leading to deployment failure."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:222
+#, no-c-format
+msgid ""
+"Farmed deployment is not atomic. A problem deploying, undeploying or "
+"redeploying an application on one node in the cluster will not prevent the "
+"deployment, undeployment or redeployment being done on the other nodes. "
+"There is no rollback capability. Deployment is also not staggered; it is "
+"quite likely, for example, that a redeployment will happen on all nodes in "
+"the cluster simultaneously, briefly leaving no nodes in the cluster "
+"providing service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:226
+#, no-c-format
+msgid ""
+"Farming is enabled by default in the <literal>all</literal> configuration in "
+"JBoss AS distributions, so you will not have to set it up yourself. The "
+"<literal>farm-service.xml</literal> configuration file is located in the "
+"deploy/deploy.last directory. If you want to enable farming in a custom "
+"configuration, simply copy the farm-service.xml file and copy it to the "
+"JBoss deploy directory <literal>$JBOSS_HOME/server/your_own_config/deploy/"
+"deploy.last</literal>. Make sure that your custom configuration has "
+"clustering enabled."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:228
+#, no-c-format
+msgid ""
+"After deploying farm-service.xml you are ready to rumble. The required "
+"FarmMemberService MBean attributes for configuring a farm are listed below."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_Intro.xml:231
+#, no-c-format
+msgid ""
+"<?xml version=\"1.0\" encoding=\"UTF-8\"?> \n"
+"<server> \n"
+" \n"
+" <mbean code=\"org.jboss.ha.framework.server.FarmMemberService\" \n"
+" name=\"jboss:service=FarmMember,partition=DefaultPartition"
+"\"> \n"
+" ... \n"
+" \n"
+" <depends optional-attribute-name=\"ClusterPartition\" \n"
+" proxy-type=\"attribute\">\n"
+" jboss:service=${jboss.partition.name:DefaultPartition}\n"
+" </depends> \n"
+" <attribute name=\"ScanPeriod\">5000</"
+"attribute> \n"
+" <attribute name=\"URLs\">farm/</attribute> \n"
+" ...\n"
+" </mbean> \n"
+"</server>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:236
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ClusterPartition</emphasis> is a required attribute "
+"to inject the HAPartition service that the farm service uses for intra-"
+"cluster communication."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:239
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">URLs</emphasis> points to the directory where "
+"deployer watches for files to be deployed. This MBean will create this "
+"directory is if does not already exist. If a full URL is not provided, it is "
+"assumed that the value is a filesytem path relative to the configuration "
+"directory (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:244
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ScanPeriod</emphasis> specifies the interval at "
+"which the folder must be scanned for changes.. Its default value is "
+"<literal>5000</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:248
+#, no-c-format
+msgid ""
+"The farming service is an extension of the <literal>URLDeploymentScanner</"
+"literal>, which scans for hot deployments in the <literal>deploy/</literal> "
+"directory. So, you can use all the attributes defined in the "
+"<literal>URLDeploymentScanner</literal> MBean in the "
+"<literal>FarmMemberService</literal> MBean. In fact, the <literal>URLs</"
+"literal> and <literal>ScanPeriod</literal> attributes listed above are "
+"inherited from the <literal>URLDeploymentScanner</literal> MBean."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_Intro.xml:257
+#, no-c-format
+msgid "Distributed state replication services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:258
+#, no-c-format
+msgid ""
+"In a clustered server environment, distributed state management is a key "
+"service the cluster must provide. For instance, in a stateful session bean "
+"application, the session state must be synchronized among all bean instances "
+"across all nodes, so that the client application reaches the same session "
+"state no matter which node serves the request. In an entity bean "
+"application, the bean object sometimes needs to be cached across the cluster "
+"to reduce the database load. Currently, the state replication and "
+"distributed cache services in JBoss AS are provided via three ways: the "
+"<literal>HASessionState</literal> Mbean, the <literal>DistributedState</"
+"literal> MBean and the JBoss Cache framework."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:265
+#, no-c-format
+msgid ""
+"The <literal>HASessionState</literal> MBean is a legacy service that "
+"provides session replication and distributed cache services for EJB 2.x "
+"stateful session beans. The MBean is defined in the <literal>all/deploy/"
+"cluster-service.xml</literal> file. We will show its configuration options "
+"in the EJB 2.x stateful session bean section later."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:268
+#, no-c-format
+msgid ""
+"The <literal>DistributedState</literal> Mbean is a legacy service built on "
+"the HAPartition service. It is supported for backwards compatibility "
+"reasons, but new applications should not use it; they should use the much "
+"more sophisticated JBoss Cache instead."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_Intro.xml:274
+#, no-c-format
+msgid ""
+"As mentioned above JBoss Cache is used to provide cache services for HTTP "
+"sessions, EJB 3.0 session beans and EJB 3.0 entity beans. It is the primary "
+"distributed state management tool in JBoss AS, and is an excellent choice "
+"for any custom caching requirements your applications may have. We will "
+"cover JBoss Cache in more detail when we discuss specific services in the "
+"next several sections.."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JBoss_Cache_JGroups.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,2343 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:5
+#, no-c-format
+msgid "JBossCache and JGroups Services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:6
+#, no-c-format
+msgid ""
+"JGroups and JBossCache provide the underlying communication, node "
+"replication and caching services, for JBoss AS clusters. Those services are "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:10
+#, no-c-format
+msgid ""
+"The JBoss AS ships with a reasonable set of default JGroups and JBossCache "
+"MBean configurations. Most applications just work out of the box with the "
+"default MBean configurations. You only need to tweak them when you are "
+"deploying an application that has special network or performance "
+"requirements."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:15
+#, no-c-format
+msgid "JGroups Configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:16
+#, no-c-format
+msgid ""
+"The JGroups framework provides services to enable peer-to-peer "
+"communications between nodes in a cluster. It is built on top a stack of "
+"network communication protocols that provide transport, discovery, "
+"reliability and failure detection, and cluster membership management "
+"services. <xref linkend=\"jbosscache-JGroupsStack.fig\"/> shows the protocol "
+"stack in JGroups."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:20
+#, no-c-format
+msgid "Protocol stack in JGroups"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:27
+#, no-c-format
+msgid ""
+"JGroups configurations often appear as a nested attribute in cluster related "
+"MBean services, such as the <literal>PartitionConfig</literal> attribute in "
+"the <literal>ClusterPartition</literal> MBean or the <literal>ClusterConfig</"
+"literal> attribute in the <literal>TreeCache</literal> MBean. You can "
+"configure the behavior and properties of each protocol in JGroups via those "
+"MBean attributes. Below is an example JGroups configuration in the "
+"<literal>ClusterPartition</literal> MBean."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:32
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<mbean code=\"org.jboss.ha.framework.server.ClusterPartition\"\n"
+" name=\"jboss:service=${jboss.partition.name:DefaultPartition}\">\n"
+" \n"
+" ... ...\n"
+" \n"
+" <attribute name=\"PartitionConfig\">\n"
+" <Config>\n"
+" \n"
+" <UDP mcast_addr=\"${jboss.partition."
+"udpGroup:228.1.2.3}\" \n"
+" mcast_port=\"${jboss.hapartition."
+"mcast_port:45566}\"\n"
+" tos=\"8\"\n"
+" ucast_recv_buf_size=\"20000000\"\n"
+" ucast_send_buf_size=\"640000\"\n"
+" mcast_recv_buf_size=\"25000000\"\n"
+" mcast_send_buf_size=\"640000\"\n"
+" loopback=\"false\"\n"
+" discard_incompatible_packets=\"true\"\n"
+" enable_bundling=\"false\"\n"
+" max_bundle_size=\"64000\"\n"
+" max_bundle_timeout=\"30\"\n"
+" use_incoming_packet_handler=\"true\"\n"
+" use_outgoing_packet_handler=\"false\"\n"
+" ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>\n"
+" \n"
+" <PING timeout=\"2000\"\n"
+" down_thread=\"false\" up_thread=\"false\" "
+"num_initial_members=\"3\"/>\n"
+" \n"
+" <MERGE2 max_interval=\"100000\"\n"
+" down_thread=\"false\" up_thread=\"false\" "
+"min_interval=\"20000\"/>\n"
+" <FD_SOCK down_thread=\"false\" up_thread=\"false\"/"
+">\n"
+" \n"
+" <FD timeout=\"10000\" max_tries=\"5\" \n"
+" down_thread=\"false\" up_thread=\"false\" shun="
+"\"true\"/>\n"
+" <VERIFY_SUSPECT timeout=\"1500\" down_thread=\"false"
+"\" up_thread=\"false\"/>\n"
+" <pbcast.NAKACK max_xmit_size=\"60000\"\n"
+" use_mcast_xmit=\"false\" gc_lag=\"0"
+"\"\n"
+" retransmit_timeout="
+"\"300,600,1200,2400,4800\"\n"
+" down_thread=\"false\" up_thread="
+"\"false\"\n"
+" discard_delivered_msgs=\"true\"/>\n"
+" <UNICAST timeout=\"300,600,1200,2400,3600\"\n"
+" down_thread=\"false\" up_thread=\"false\"/"
+">\n"
+" <pbcast.STABLE stability_delay=\"1000\" "
+"desired_avg_gossip=\"50000\"\n"
+" down_thread=\"false\" up_thread="
+"\"false\"\n"
+" max_bytes=\"400000\"/>\n"
+" <pbcast.GMS print_local_addr=\"true\" join_timeout="
+"\"3000\"\n"
+" down_thread=\"false\" up_thread=\"false"
+"\"\n"
+" join_retry_timeout=\"2000\" shun=\"true"
+"\"\n"
+" view_bundling=\"true\"/>\n"
+" <FRAG2 frag_size=\"60000\" down_thread=\"false\" "
+"up_thread=\"false\"/>\n"
+" <pbcast.STATE_TRANSFER down_thread=\"false\" \n"
+" up_thread=\"false\" "
+"use_flush=\"false\"/>\n"
+" </Config>\n"
+" </attribute>\n"
+"</mbean> ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:33
+#, no-c-format
+msgid ""
+"All the JGroups configuration data is contained in the <Config> "
+"element under the JGroups config MBean attribute. This information is used "
+"to configure a JGroups Channel; the Channel is conceptually similar to a "
+"socket, and manages communication between peers in a cluster. Each element "
+"inside the <Config> element defines a particular JGroups Protocol; "
+"each Protocol performs one function, and the combination of those functions "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:38
+#, no-c-format
+msgid "Common Configuration Properties"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:39
+#, no-c-format
+msgid ""
+"The following common properties are exposed by all of the JGroups protocols "
+"discussed below:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:43
+#, no-c-format
+msgid ""
+"<literal>down_thread</literal> whether the protocol should create an "
+"internal queue and a queue processing thread (aka the down_thread) for "
+"messages passed down from higher layers. The higher layer could be another "
+"protocol higher in the stack, or the application itself, if the protocol is "
+"the top one on the stack. If true (the default), when a message is passed "
+"down from a higher layer, the calling thread places the message in the "
+"protocol's queue, and then returns immediately. The protocol's down_thread "
+"is responsible for reading messages off the queue, doing whatever protocol-"
+"specific processing is required, and passing the message on to the next "
+"protocol in the stack."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:47
+#, no-c-format
+msgid ""
+"<literal>up_thread</literal> is conceptually similar to down_thread, but "
+"here the queue and thread are for messages received from lower layers in the "
+"protocol stack."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:51
+#, no-c-format
+msgid ""
+"Generally speaking, <literal>up_thread</literal> and <literal>down_thread</"
+"literal> should be set to false."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:57
+#, no-c-format
+msgid "Transport Protocols"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:58
+#, no-c-format
+msgid ""
+"The transport protocols send messages from one cluster node to another "
+"(unicast) or from cluster node to all other nodes in the cluster (mcast). "
+"JGroups supports UDP, TCP, and TUNNEL as transport protocols."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:62
+#, no-c-format
+msgid ""
+"The <literal>UDP</literal>, <literal>TCP</literal>, and <literal>TUNNEL</"
+"literal> elements are mutually exclusive. You can only have one transport "
+"protocol in each JGroups <literal>Config</literal> element"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:67
+#, no-c-format
+msgid "UDP configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:68
+#, no-c-format
+msgid ""
+"UDP is the preferred protocol for JGroups. UDP uses multicast or multiple "
+"unicasts to send and receive messages. If you choose UDP as the transport "
+"protocol for your cluster service, you need to configure it in the "
+"<literal>UDP</literal> sub-element in the JGroups <literal>Config</literal> "
+"element. Here is an example."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:72
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\" \n"
+" mcast_port=\"${jboss.hapartition.mcast_port:45566}\"\n"
+" tos=\"8\"\n"
+" ucast_recv_buf_size=\"20000000\"\n"
+" ucast_send_buf_size=\"640000\"\n"
+" mcast_recv_buf_size=\"25000000\"\n"
+" mcast_send_buf_size=\"640000\"\n"
+" loopback=\"false\"\n"
+" discard_incompatible_packets=\"true\"\n"
+" enable_bundling=\"false\"\n"
+" max_bundle_size=\"64000\"\n"
+" max_bundle_timeout=\"30\"\n"
+" use_incoming_packet_handler=\"true\"\n"
+" use_outgoing_packet_handler=\"false\"\n"
+" ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:75
+#, no-c-format
+msgid ""
+"The available attributes in the above JGroups configuration are listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:78
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ip_mcast</emphasis> specifies whether or not to use "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:83
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">mcast_addr</emphasis> specifies the multicast "
+"address (class D) for joining a group (i.e., the cluster). If omitted, the "
+"default is <literal>228.8.8.8 </literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:88
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">mcast_port</emphasis> specifies the multicast port "
+"number. If omitted, the default is <literal>45566</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:92
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on "
+"which to receive and send multicasts (uses the <literal>-Djgroups."
+"bind_address</literal> system property, if present). If you have a "
+"multihomed machine, set the <literal>bind_addr</literal> attribute or system "
+"property to the appropriate NIC IP address. By default, system property "
+"setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr "
+"system property is set."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:95
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">receive_on_all_interfaces </emphasis> specifies "
+"whether this node should listen on all interfaces for multicasts. The "
+"default is <literal>false</literal>. It overrides the <literal>bind_addr</"
+"literal> property for receiving multicasts. However, <literal>bind_addr</"
+"literal> (if set) is still used to send multicasts."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:100
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">send_on_all_interfaces</emphasis> specifies whether "
+"this node send UDP packets via all the NICs if you have a multi NIC machine. "
+"This means that the same multicast message is sent N times, so use with care."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:105
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">receive_interfaces</emphasis> specifies a list of of "
+"interfaces to receive multicasts on. The multicast receive socket will "
+"listen on all of these interfaces. This is a comma-separated list of IP "
+"addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</"
+"literal>\"."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:111
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">ip_ttl</emphasis> specifies time-to-live for IP "
+"Multicast packets. TTL is the commonly used term in multicast networking, "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:115
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">use_incoming_packet_handler</emphasis> specifies "
+"whether to use a separate thread to process incoming messages. Sometimes "
+"receivers are overloaded (they have to handle de-serialization etc). Packet "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:118
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">use_outgoing_packet_handler</emphasis> specifies "
+"whether to use a separate thread to process outgoing messages. The default "
+"is false."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:121
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">enable_bundling</emphasis> specifies whether to "
+"enable message bundling. If it is <literal>true</literal>, the node would "
+"queue outgoing messages until <literal>max_bundle_size</literal> bytes have "
+"accumulated, or <literal>max_bundle_time</literal> milliseconds have "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:129
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:134
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">discard_incompatibe_packets</emphasis> specifies "
+"whether to discard packets from different JGroups versions. Each message in "
+"the cluster is tagged with a JGroups version. When a message from a "
+"different version of JGroups is received, it will be discarded if set to "
+"true, otherwise a warning will be logged. The default is <literal>false</"
+"literal>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:140
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">mcast_send_buf_size, mcast_recv_buf_size, "
+"ucast_send_buf_size, ucast_recv_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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:146
+#, no-c-format
+msgid ""
+"<literal>tos</literal> specifies traffic class for sending unicast and "
+"multicast datagrams."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:152
+#, no-c-format
+msgid ""
+"On Windows 2000 machines, because of the media sense feature being broken "
+"with multicast (even after disabling media sense), you need to set the UDP "
+"protocol's <literal>loopback</literal> attribute to <literal>true</literal>."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:160
+#, no-c-format
+msgid "TCP configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:161
+#, no-c-format
+msgid ""
+"Alternatively, a JGroups-based cluster can also work over TCP connections. "
+"Compared with UDP, TCP generates more network traffic when the cluster size "
+"increases. TCP is fundamentally a unicast protocol. To send multicast "
+"messages, JGroups uses multiple TCP unicasts. To use TCP as a transport "
+"protocol, you should define a <literal>TCP</literal> element in the JGroups "
+"<literal>Config</literal> element. Here is an example of the <literal>TCP</"
+"literal> element."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:167
+#, no-c-format
+msgid ""
+"<TCP start_port=\"7800\"\n"
+" bind_addr=\"192.168.5.1\"\n"
+" loopback=\"true\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:168
+#, no-c-format
+msgid ""
+"Below are the attributes available in the <literal>TCP</literal> element."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:171
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bind_addr</emphasis> specifies the binding address. "
+"It can also be set with the <literal>-Djgroups.bind_address</literal> "
+"command line option at server startup."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:176
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">start_port, end_port</emphasis> define the range of "
+"TCP ports the server should bind to. The server socket is bound to the first "
+"available port from <literal>start_port</literal>. If no available port is "
+"found (e.g., because of a firewall) before the <literal>end_port</literal>, "
+"the server throws an exception. If no <literal>end_port</literal> is "
+"provided or <literal>end_port < start_port</literal> then there is no "
+"upper limit on the port range. If <literal>start_port == end_port</literal>, "
+"then we force JGroups to use the given port (start fails if port is not "
+"available). The default is 7800. If set to 0, then the operating system will "
+"pick a port. Please, bear in mind that setting it to 0 will work only if we "
+"use MPING or TCPGOSSIP as discovery protocol because <literal>TCCPING</"
+"literal> requires listing the nodes and their corresponding ports."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:182
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop "
+"outgoing message back up the stack. In <literal>unicast</literal> mode, the "
+"messages are sent to self. In <literal>mcast</literal> mode, a copy of the "
+"mcast message is sent. The default is false."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:187
+#, no-c-format
+msgid ""
+"<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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:190
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">conn_expire_time</emphasis> specifies the time (in "
+"milliseconds) after which a connection can be closed by the reaper if no "
+"traffic has been received."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:195
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">reaper_interval</emphasis> specifies interval (in "
+"milliseconds) to run the reaper. If both values are 0, no reaping will be "
+"done. If either value is > 0, reaping will be enabled. By default, "
+"reaper_interval is 0, which means no reaper."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:200
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">sock_conn_timeout</emphasis> specifies max time in "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:203
+#, no-c-format
+msgid ""
+"<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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:206
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">external_addr</emphasis> specifies external IP "
+"address to broadcast to other group members (if different to local address). "
+"This is useful when you have use (Network Address Translation) NAT, e.g. a "
+"node on a private network, behind a firewall, but you can only route to it "
+"via an externally visible address, which is different from the local address "
+"it is bound to. Therefore, the node can be configured to broadcast its "
+"external address, while still able to bind to the local one. This avoids "
+"having to use the TUNNEL protocol, (and hence a requirement for a central "
+"gossip router) because nodes outside the firewall can still route to the "
+"node inside the firewall, but only on its external address. Without setting "
+"the external_addr, the node behind the firewall will broadcast its private "
+"address to the other nodes which will not be able to route to it."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:209
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">skip_suspected_members</emphasis> specifies whether "
+"unicast messages should not be sent to suspected members. The default is "
+"true."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:212
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">tcp_nodelay</emphasis> specifies TCP_NODELAY. TCP by "
+"default nagles messages, that is, conceptually, smaller messages are bundled "
+"into larger ones. If we want to invoke synchronous cluster method calls, "
+"then we need to disable nagling in addition to disabling message bundling "
+"(by setting <literal>enable_bundling</literal> to false). Nagling is "
+"disabled by setting <literal>tcp_nodelay</literal> to true. The default is "
+"false."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:220
+#, no-c-format
+msgid "TUNNEL configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:221
+#, no-c-format
+msgid ""
+"The TUNNEL protocol uses an external router to send messages. The external "
+"router is known as a <literal>GossipRouter</literal>. Each node has to "
+"register with the router. All messages are sent to the router and forwarded "
+"on to their destinations. The TUNNEL approach can be used to setup "
+"communication with nodes behind firewalls. A node can establish a TCP "
+"connection to the GossipRouter through the firewall (you can use port 80). "
+"The same connection is used by the router to send messages to nodes behind "
+"the firewall as most firewalls do not permit outside hosts to initiate a TCP "
+"connection to a host inside the firewall. The TUNNEL configuration is "
+"defined in the TUNNEL element in the JGroups Config element. Here is an "
+"example.."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:226
+#, no-c-format
+msgid ""
+"<TUNNEL router_port=\"12001\"\n"
+" router_host=\"192.168.5.1\"\n"
+" down_thread=\"false\" up_thread=\"false/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:229
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>TUNNEL</literal> element are listed "
+"below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:232
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">router_host</emphasis> specifies the host on which "
+"the GossipRouter is running."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:236
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">router_port</emphasis> specifies the port on which "
+"the GossipRouter is listening."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:240
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">loopback</emphasis> specifies whether to loop "
+"messages back up the stack. The default is <literal>true</literal>."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:251
+#, no-c-format
+msgid "Discovery Protocols"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:252
+#, no-c-format
+msgid ""
+"The cluster needs to maintain a list of current member nodes at all times so "
+"that the load balancer and client interceptor know how to route their "
+"requests. Discovery protocols are used to discover active nodes in the "
+"cluster and detect the oldest member of the cluster, which is the "
+"coordinator. All initial nodes are discovered when the cluster starts up. "
+"When a new node joins the cluster later, it is only discovered after the "
+"group membership protocol (GMS, see <xref linkend=\"jbosscache-jgroups-other-"
+"gms\"/>) admits it into the group."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:256
+#, no-c-format
+msgid ""
+"Since the discovery protocols sit on top of the transport protocol, you can "
+"choose to use different discovery protocols based on your transport "
+"protocol. These are also configured as sub-elements in the JGroups MBean "
+"<literal>Config</literal> element."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:262
+#, no-c-format
+msgid "PING"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:263
+#, no-c-format
+msgid ""
+"PING is a discovery protocol that works by either multicasting PING requests "
+"to an IP multicast address or connecting to a gossip router. As such, PING "
+"normally sits on top of the UDP or TUNNEL transport protocols. Each node "
+"responds with a packet {C, A}, where C=coordinator's address and A=own "
+"address. After timeout milliseconds or num_initial_members replies, the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:266
+#, no-c-format
+msgid "Here is an example PING configuration for IP multicast."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:270
+#, no-c-format
+msgid ""
+"<PING timeout=\"2000\"\n"
+" num_initial_members=\"2\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:271
+#, no-c-format
+msgid ""
+"Here is another example PING configuration for contacting a Gossip Router."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:273
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<PING gossip_host=\"localhost\"\n"
+" gossip_port=\"1234\"\n"
+" timeout=\"3000\" \n"
+" num_initial_members=\"3\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:278
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>PING</literal> element are listed "
+"below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:281
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:329
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:358
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:392
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of "
+"milliseconds to wait for any responses. The default is 3000."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:285
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:333
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:362
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum "
+"number of responses to wait for unless timeout has expired. The default is 2."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:289
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">gossip_host</emphasis> specifies the host on which "
+"the GossipRouter is running."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:293
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">gossip_port</emphasis> specifies the port on which "
+"the GossipRouter is listening on."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:297
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">gossip_refresh</emphasis> specifies the interval (in "
+"milliseconds) for the lease from the GossipRouter. The default is 20000."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:301
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
+"of addresses (e.g., <literal>host1[12345],host2[23456]</literal>), which are "
+"pinged for discovery."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:306
+#, no-c-format
+msgid ""
+"If both <literal>gossip_host</literal> and <literal>gossip_port</literal> "
+"are defined, the cluster uses the GossipRouter for the initial discovery. If "
+"the <literal>initial_hosts</literal> is specified, the cluster pings that "
+"static list of addresses for discovery. Otherwise, the cluster uses IP "
+"multicasting for discovery."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:311
+#, no-c-format
+msgid ""
+"The discovery phase returns when the <literal>timeout</literal> ms have "
+"elapsed or the <literal>num_initial_members</literal> responses have been "
+"received."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:319
+#, no-c-format
+msgid "TCPGOSSIP"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:320
+#, no-c-format
+msgid ""
+"The TCPGOSSIP protocol only works with a GossipRouter. It works essentially "
+"the same way as the PING protocol configuration with valid "
+"<literal>gossip_host</literal> and <literal>gossip_port</literal> "
+"attributes. It works on top of both UDP and TCP transport protocols. Here is "
+"an example."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:323
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<TCPGOSSIP timeout=\"2000\"\n"
+" initial_hosts=\"192.168.5.1[12000],192.168.0.2[12000]\"\n"
+" num_initial_members=\"3\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:326
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>TCPGOSSIP</literal> element are "
+"listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:337
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
+"of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for "
+"GossipRouters to register with."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:347
+#, no-c-format
+msgid "TCPPING"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:348
+#, no-c-format
+msgid ""
+"The TCPPING protocol takes a set of known members and ping them for "
+"discovery. This is essentially a static configuration. It works on top of "
+"TCP. Here is an example of the <literal>TCPPING</literal> configuration "
+"element in the JGroups <literal>Config</literal> element."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:352
+#, no-c-format
+msgid ""
+"<TCPPING timeout=\"2000\"\n"
+" initial_hosts=\"hosta[2300],hostb[3400],hostc[4500]\"\n"
+" port_range=\"3\"\n"
+" num_initial_members=\"3\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:355
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>TCPPING</literal> element are "
+"listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:366
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list "
+"of addresses (e.g., <literal>host1[12345],host2[23456]</literal>) for "
+"pinging."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:370
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">port_range</emphasis> specifies the number of "
+"consecutive ports to be probed when getting the initial membership, starting "
+"with the port specified in the initial_hosts parameter. Given the current "
+"values of port_range and initial_hosts above, the TCPPING layer will try to "
+"connect to hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, "
+"hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options "
+"allows for multiple nodes on the same host to be pinged."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:381
+#, no-c-format
+msgid "MPING"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:382
+#, no-c-format
+msgid ""
+"MPING uses IP multicast to discover the initial membership. It can be used "
+"with all transports, but usually this is used in combination with TCP. TCP "
+"usually requires TCPPING, which has to list all group members explicitly, "
+"but MPING doesn't have this requirement. The typical use case for this is "
+"when we want TCP as transport, but multicasting for discovery so we don't "
+"have to define a static list of initial hosts in TCPPING or require external "
+"Gossip Router."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:386
+#, no-c-format
+msgid ""
+"<MPING timeout=\"2000\"\n"
+" bind_to_all_interfaces=\"true\"\n"
+" mcast_addr=\"228.8.8.8\"\n"
+" mcast_port=\"7500\"\n"
+" ip_ttl=\"8\"\n"
+" num_initial_members=\"3\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:389
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>MPING</literal> element are listed "
+"below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:396
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">num_initial_members</emphasis> specifies the maximum "
+"number of responses to wait for unless timeout has expired. The default is "
+"2.."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:400
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on "
+"which to send and receive multicast packets."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:404
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bind_to_all_interfaces</emphasis> overrides the "
+"<literal>bind_addr</literal> and uses all interfaces in multihome nodes."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:408
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">mcast_addr, mcast_port, ip_ttl</emphasis> attributes "
+"are the same as related attributes in the UDP protocol configuration."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:418
+#, no-c-format
+msgid "Failure Detection Protocols"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:419
+#, no-c-format
+msgid ""
+"The failure detection protocols are used to detect failed nodes. Once a "
+"failed node is detected, a suspect verification phase can occur after which, "
+"if the node is still considered dead, the cluster updates its view so that "
+"the load balancer and client interceptors know to avoid the dead node. The "
+"failure detection protocols are configured as sub-elements in the JGroups "
+"MBean <literal>Config</literal> element."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:425
+#, no-c-format
+msgid "<title>FD</title>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:426
+#, no-c-format
+msgid ""
+"FD is a failure detection protocol based on heartbeat messages. This "
+"protocol requires each node to periodically send are-you-alive messages to "
+"its neighbour. If the neighbour fails to respond, the calling node sends a "
+"SUSPECT message to the cluster. The current group coordinator can optionally "
+"double check whether the suspected node is indeed dead after which, if the "
+"node is still considered dead, updates the cluster's view. Here is an "
+"example FD configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:430
+#, no-c-format
+msgid ""
+"<FD timeout=\"2000\"\n"
+" max_tries=\"3\"\n"
+" shun=\"true\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:433
+#, no-c-format
+msgid ""
+"The available attributes in the <literal>FD</literal> element are listed "
+"below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:436
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">timeout</emphasis> specifies the maximum number of "
+"milliseconds to wait for the responses to the are-you-alive messages. The "
+"default is 3000."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:440
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">max_tries</emphasis> specifies the number of missed "
+"are-you-alive messages from a node before the node is suspected. The default "
+"is 2."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:444
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">shun</emphasis> specifies whether a failed node will "
+"be shunned. Once shunned, the node will be expelled from the cluster even if "
+"it comes back later. The shunned node would have to re-join the cluster "
+"through the discovery process. JGroups allows to configure itself such that "
+"shunning leads to automatic rejoins and state transfer, which is the default "
+"behaivour within JBoss Application Server."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:450
+#, no-c-format
+msgid ""
+"Regular traffic from a node counts as if it is a live. So, the are-you-alive "
+"messages are only sent when there is no regular traffic to the node for "
+"sometime."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:459
+#, no-c-format
+msgid "FD_SOCK"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:460
+#, no-c-format
+msgid ""
+"FD_SOCK is a failure detection protocol based on a ring of TCP sockets "
+"created between group members. Each member in a group connects to its "
+"neighbor (last member connects to first) thus forming a ring. Member B is "
+"suspected when its neighbor A detects abnormally closed TCP socket "
+"(presumably due to a node B crash). However, if a member B is about to leave "
+"gracefully, it lets its neighbor A know, so that it does not become "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:464
+#, no-c-format
+msgid "<FD_SOCK_down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:466
+#, no-c-format
+msgid ""
+"There available attributes in the <literal>FD_SOCK</literal> element are "
+"listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:469
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface to "
+"which the server socket should bind to. If -Djgroups.bind_address system "
+"property is defined, XML value will be ignore. This behaivour can be "
+"reversed setting -Djgroups.ignore.bind_addr=true system property."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:477
+#, no-c-format
+msgid "VERIFY_SUSPECT"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:478
+#, no-c-format
+msgid ""
+"This protocol verifies whether a suspected member is really dead by pinging "
+"that member once again. This verification is performed by the coordinator of "
+"the cluster. The suspected member is dropped from the cluster group if "
+"confirmed to be dead. The aim of this protocol is to minimize false "
+"suspicions. Here's an example."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:482
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<VERIFY_SUSPECT timeout=\"1500\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:484
+#, no-c-format
+msgid "The available attributes in the FD_SOCK element are listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:489
+#, no-c-format
+msgid ""
+"timeout specifies how long to wait for a response from the suspected member "
+"before considering it dead."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:500
+#, no-c-format
+msgid "FD versus FD_SOCK"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:501
+#, no-c-format
+msgid ""
+"FD and FD_SOCK, each taken individually, do not provide a solid failure "
+"detection layer. Let's look at the the differences between these failure "
+"detection protocols to understand how they complement each other:"
+msgstr ""
+
+#. Tag: emphasis
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:505
+#, no-c-format
+msgid "<emphasis>FD</emphasis>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:510
+#, no-c-format
+msgid "An overloaded machine might be slow in sending are-you-alive responses."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:515
+#, no-c-format
+msgid "A member will be suspected when suspended in a debugger/profiler."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:520
+#, no-c-format
+msgid ""
+"Low timeouts lead to higher probability of false suspicions and higher "
+"network traffic."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:525
+#, no-c-format
+msgid "High timeouts will not detect and remove crashed members for some time."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:532
+#, no-c-format
+msgid "<emphasis>FD_SOCK</emphasis>:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:538
+#, no-c-format
+msgid ""
+"Suspended in a debugger is no problem because the TCP connection is still "
+"open."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:543
+#, no-c-format
+msgid "High load no problem either for the same reason."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:548
+#, no-c-format
+msgid "Members will only be suspected when TCP connection breaks"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:557
+#, no-c-format
+msgid "So hung members will not be detected."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:562
+#, no-c-format
+msgid ""
+"Also, a crashed switch will not be detected until the connection runs into "
+"the TCP timeout (between 2-20 minutes, depending on TCP/IP stack "
+"implementation)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:569
+#, no-c-format
+msgid ""
+"The aim of a failure detection layer is to report real failures and "
+"therefore avoid false suspicions. There are two solutions:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:574
+#, no-c-format
+msgid ""
+"By default, JGroups configures the FD_SOCK socket with KEEP_ALIVE, which "
+"means that TCP sends a heartbeat on socket on which no traffic has been "
+"received in 2 hours. If a host crashed (or an intermediate switch or router "
+"crashed) without closing the TCP connection properly, we would detect this "
+"after 2 hours (plus a few minutes). This is of course better than never "
+"closing the connection (if KEEP_ALIVE is off), but may not be of much help. "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:579
+#, no-c-format
+msgid ""
+"The second solution is to combine FD_SOCK and FD; the timeout in FD can be "
+"set such that it is much lower than the TCP timeout, and this can be "
+"configured individually per process. FD_SOCK will already generate a suspect "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:584
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<FD_SOCK down_thread=\"false\" up_thread=\"false\"/>\n"
+"<FD timeout=\"10000\" max_tries=\"5\" shun=\"true\" \n"
+"down_thread=\"false\" up_thread=\"false\" /> ]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:586
+#, no-c-format
+msgid ""
+"This suspects a member when the socket to the neighbor has been closed "
+"abonormally (e.g. process crash, because the OS closes all sockets). "
+"However, f a host or switch crashes, then the sockets won't be closed, "
+"therefore, as a seond line of defense, FD will suspect the neighbor after 50 "
+"seconds. Note that with this example, if you have your system stopped in a "
+"breakpoint in the debugger, the node you're debugging will be suspected "
+"after ca 50 seconds."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:589
+#, no-c-format
+msgid ""
+"A combination of FD and FD_SOCK provides a solid failure detection layer and "
+"for this reason, such technique is used accross JGroups configurations "
+"included within JBoss Application Server."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:598
+#, no-c-format
+msgid "Reliable Delivery Protocols"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:599
+#, no-c-format
+msgid ""
+"Reliable delivery protocols within the JGroups stack ensure that data "
+"pockets are actually delivered in the right order (FIFO) to the destination "
+"node. The basis for reliable message delivery is positive and negative "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:606
+#, no-c-format
+msgid "UNICAST"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:607
+#, no-c-format
+msgid ""
+"The UNICAST protocol is used for unicast messages. It uses ACK. It is "
+"configured as a sub-element under the JGroups Config element. If the JGroups "
+"stack is configured with TCP transport protocol, UNICAST is not necessary "
+"because TCP itself guarantees FIFO delivery of unicast messages. Here is an "
+"example configuration for the <literal>UNICAST</literal> protocol."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:610
+#, no-c-format
+msgid ""
+"<UNICAST timeout=\"100,200,400,800\"\n"
+"down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:612
+#, no-c-format
+msgid ""
+"There is only one configurable attribute in the <literal>UNICAST</literal> "
+"element."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:615
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">timeout</emphasis> specifies the retransmission "
+"timeout (in milliseconds). For instance, if the timeout is \"100,200,400,800"
+"\", the sender resends the message if it hasn't received an ACK after 100 ms "
+"the first time, and the second time it waits for 200 ms before resending, "
+"and so on."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:625
+#, no-c-format
+msgid "NAKACK"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:626
+#, no-c-format
+msgid ""
+"The NAKACK protocol is used for multicast messages. It uses NAK. Under this "
+"protocol, each message is tagged with a sequence number. The receiver keeps "
+"track of the sequence numbers and deliver the messages in order. When a gap "
+"in the sequence number is detected, the receiver asks the sender to "
+"retransmit the missing message. The NAKACK protocol is configured as the "
+"<literal>pbcast.NAKACK</literal> sub-element under the JGroups "
+"<literal>Config</literal> element. Here is an example configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:633
+#, no-c-format
+msgid ""
+"<pbcast.NAKACK max_xmit_size=\"60000\" use_mcast_xmit=\"false\" \n"
+" \n"
+" retransmit_timeout=\"300,600,1200,2400,4800\" gc_lag=\"0\"\n"
+" discard_delivered_msgs=\"true\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:636
+#, no-c-format
+msgid ""
+"The configurable attributes in the <literal>pbcast.NAKACK</literal> element "
+"are as follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:639
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">retransmit_timeout</emphasis> specifies the "
+"retransmission timeout (in milliseconds). It is the same as the "
+"<literal>timeout</literal> attribute in the UNICAST protocol."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:644
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">use_mcast_xmit</emphasis> determines whether the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:650
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">max_xmit_size</emphasis> specifies maximum size for "
+"a bundled retransmission, if multiple packets are reported missing."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:654
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">discard_delivered_msgs</emphasis> specifies whether "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:661
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">gc_lag specifies</emphasis> the number of messages "
+"garbage collection lags behind."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:672
+#, no-c-format
+msgid "Other Configuration Options"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:673
+#, no-c-format
+msgid ""
+"In addition to the protocol stacks, you can also configure JGroups network "
+"services in the <literal>Config</literal> element."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:677
+#, no-c-format
+msgid "Group Membership"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:678
+#, no-c-format
+msgid ""
+"The group membership service in the JGroups stack maintains a list of active "
+"nodes. It handles the requests to join and leave the cluster. It also "
+"handles the SUSPECT messages sent by failure detection protocols. All nodes "
+"in the cluster, as well as the load balancer and client side interceptors, "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:684
+#, no-c-format
+msgid ""
+"<pbcast.GMS print_local_addr=\"true\"\n"
+" join_timeout=\"3000\"\n"
+" down_thread=\"false\" up_thread=\"false\"\n"
+" join_retry_timeout=\"2000\"\n"
+" shun=\"true\"\n"
+" view_bundling=\"true\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:688
+#, no-c-format
+msgid ""
+"The configurable attributes in the <literal>pbcast.GMS</literal> element are "
+"as follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:691
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">join_timeout</emphasis> specifies the maximum number "
+"of milliseconds to wait for a new node JOIN request to succeed. Retry "
+"afterwards."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:695
+#, no-c-format
+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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:699
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">print_local_addr</emphasis> specifies whether to "
+"dump the node's own address to the output when started."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:703
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">shun</emphasis> specifies whether a node should shun "
+"itself if it receives a cluster view that it is not a member node."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:707
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">disable_initial_coord</emphasis> specifies whether "
+"to prevent this node as the cluster coordinator."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:711
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">view_bundling</emphasis> specifies whether multiple "
+"JOIN or LEAVE request arriving at the same time are bundled and handled "
+"together at the same time, only sending out 1 new view / bundle. This is is "
+"more efficient than handling each request separately."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:720
+#, no-c-format
+msgid "Flow Control"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:721
+#, no-c-format
+msgid ""
+"The flow control service tries to adapt the sending data rate and the "
+"receiving data among nodes. If a sender node is too fast, it might overwhelm "
+"the receiver node and result in dropped packets that have to be "
+"retransmitted. In JGroups, the flow control is implemented via a credit-"
+"based system. The sender and receiver nodes have the same number of credits "
+"(bytes) to start with. The sender subtracts credits by the number of bytes "
+"in messages it sends. The receiver accumulates credits for the bytes in the "
+"messages it receives. When the sender's credit drops to a threshold, the "
+"receivers sends some credit to the sender. If the sender's credit is used "
+"up, the sender blocks until it receives credits from the receiver. The flow "
+"control service is configured in the <literal>FC</literal> sub-element under "
+"the JGroups <literal>Config</literal> element. Here is an example "
+"configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:732
+#, no-c-format
+msgid ""
+"<FC max_credits=\"1000000\"\n"
+"down_thread=\"false\" up_thread=\"false\" \n"
+" min_threshold=\"0.10\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:735
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:831
+#, no-c-format
+msgid ""
+"The configurable attributes in the <literal>FC</literal> element are as "
+"follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:738
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">max_credits</emphasis> specifies the maximum number "
+"of credits (in bytes). This value should be smaller than the JVM heap size."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:742
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">min_credits</emphasis> specifies the threshold "
+"credit on the sender, below which the receiver should send in more credits."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:746
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">min_threshold</emphasis> specifies percentage value "
+"of the threshold. It overrides the <literal>min_credits</literal> attribute."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:751
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:775
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:752
+#, no-c-format
+msgid ""
+"Applications that use synchronous group RPC calls primarily do not require "
+"FC protocol in their JGroups protocol stack because synchronous "
+"communication, where the hread that makes the call blocks waiting for "
+"responses from all the members of the group, already slows overall rate of "
+"calls. Even though TCP provides flow control by itself, FC is still required "
+"in TCP based JGroups stacks because of group communication, where we "
+"essentially have to send group messages at the highest speed the slowest "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:761
+#, no-c-format
+msgid "Fragmentation"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:762
+#, no-c-format
+msgid ""
+"This protocol fragments messages larger than certain size. Unfragments at "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:765
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+" <FRAG2 frag_size=\"60000\" down_thread=\"false\" up_thread="
+"\"false\"/>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:767
+#, no-c-format
+msgid "The configurable attributes in the FRAG2 element are as follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:772
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">frag_size</emphasis> specifies the max frag size in "
+"bytes. Messages larger than that are fragmented."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:776
+#, no-c-format
+msgid ""
+"TCP protocol already provides fragmentation but a fragmentation JGroups "
+"protocol is still needed if FC is used. The reason for this is that if you "
+"send a message larger than FC.max_bytes, FC protocol would block. So, "
+"frag_size within FRAG2 needs to be set to always be less than FC.max_bytes."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:785
+#, no-c-format
+msgid "State Transfer"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:786
+#, no-c-format
+msgid ""
+"The state transfer service transfers the state from an existing node (i.e., "
+"the cluster coordinator) to a newly joining node. It is configured in the "
+"<literal>pbcast.STATE_TRANSFER</literal> sub-element under the JGroups "
+"<literal>Config</literal> element. It does not have any configurable "
+"attribute. Here is an example configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:790
+#, no-c-format
+msgid ""
+"<pbcast.STATE_TRANSFER down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:794
+#, no-c-format
+msgid "Distributed Garbage Collection"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:795
+#, no-c-format
+msgid ""
+"In a JGroups cluster, all nodes have to store all messages received for "
+"potential retransmission in case of a failure. However, if we store all "
+"messages forever, we will run out of memory. So, the distributed garbage "
+"collection service in JGroups periodically purges messages that have seen by "
+"all nodes from the memory in each node. The distributed garbage collection "
+"service is configured in the <literal>pbcast.STABLE</literal> sub-element "
+"under the JGroups <literal>Config</literal> element. Here is an example "
+"configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:799
+#, no-c-format
+msgid ""
+"<pbcast.STABLE stability_delay=\"1000\"\n"
+" desired_avg_gossip=\"5000\" \n"
+" down_thread=\"false\" up_thread=\"false\"\n"
+" max_bytes=\"400000\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:801
+#, no-c-format
+msgid ""
+"The configurable attributes in the <literal>pbcast.STABLE</literal> element "
+"are as follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:804
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">desired_avg_gossip</emphasis> specifies intervals "
+"(in milliseconds) of garbage collection runs. Value <literal>0</literal> "
+"disables this service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:809
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">max_bytes</emphasis> specifies the maximum number of "
+"bytes received before the cluster triggers a garbage collection run. Value "
+"<literal>0</literal> disables this service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:814
+#, no-c-format
+msgid ""
+"<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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:818
+#, no-c-format
+msgid ""
+"Set the <literal>max_bytes</literal> attribute when you have a high traffic "
+"cluster."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:823
+#, no-c-format
+msgid "Merging"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:824
+#, no-c-format
+msgid ""
+"When a network error occurs, the cluster might be partitioned into several "
+"different partitions. JGroups has a MERGE service that allows the "
+"coordinators in partitions to communicate with each other and form a single "
+"cluster back again. The flow control service is configured in the "
+"<literal>MERGE2</literal> sub-element under the JGroups <literal>Config</"
+"literal> element. Here is an example configuration."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:828
+#, no-c-format
+msgid ""
+"<MERGE2 max_interval=\"10000\"\n"
+" min_interval=\"2000\"\n"
+" down_thread=\"false\" up_thread=\"false\"/>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:834
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">max_interval</emphasis> specifies the maximum number "
+"of milliseconds to send out a MERGE message."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:838
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">min_interval</emphasis> specifies the minimum number "
+"of milliseconds to send out a MERGE message."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:842
+#, no-c-format
+msgid ""
+"JGroups chooses a random value between <literal>min_interval</literal> and "
+"<literal>max_interval</literal> to send out the MERGE message."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:845
+#, no-c-format
+msgid ""
+"The cluster states are not merged in a merger. This has to be done by the "
+"application. If <literal>MERGE2</literal> is used in conjunction with "
+"TCPPING, the <literal>initial_hosts</literal> attribute must contain all the "
+"nodes that could potentially be merged back, in order for the merge process "
+"to work properly. Otherwise, the merge process would not merge all the nodes "
+"even though shunning is disabled. Alternatively use MPING, which is commonly "
+"used with TCP to provide multicast member discovery capabilities, instead of "
+"TCPPING to avoid having to specify all the nodes."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:851
+#, no-c-format
+msgid "Binding JGroups Channels to a particular interface"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:852
+#, no-c-format
+msgid ""
+"In the Transport Protocols section above, we briefly touched on how the "
+"interface to which JGroups will bind sockets is configured. Let's get into "
+"this topic in more depth:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:855
+#, no-c-format
+msgid ""
+"First, it's important to understand that the value set in any bind_addr "
+"element in an XML configuration file will be ignored by JGroups if it finds "
+"that system property jgroups.bind_addr (or a deprecated earlier name for the "
+"same thing, <literal>bind.address</literal>) has been set. The system "
+"property trumps XML. If JBoss AS is started with the -b (a.k.a. --host) "
+"switch, the AS will set <literal>jgroups.bind_addr</literal> to the "
+"specified value."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:858
+#, no-c-format
+msgid ""
+"Beginning with AS 4.2.0, for security reasons the AS will bind most services "
+"to localhost if -b is not set. The effect of this is that in most cases "
+"users are going to be setting -b and thus jgroups.bind_addr is going to be "
+"set and any XML setting will be ignored."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:861
+#, no-c-format
+msgid ""
+"So, what are <emphasis>best practices</emphasis> for managing how JGroups "
+"binds to interfaces?"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:866
+#, no-c-format
+msgid ""
+"Binding JGroups to the same interface as other services. Simple, just use -b:"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:868
+#, no-c-format
+msgid "./run.sh -b 192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:872
+#, no-c-format
+msgid ""
+"Binding services (e.g., JBoss Web) to one interface, but use a different one "
+"for JGroups: <screen>./run.sh -b 10.0.0.100 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen> Specifically setting the system "
+"property overrides the -b value. This is a common usage pattern; put client "
+"traffic on one network, with intra-cluster traffic on another."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:880
+#, no-c-format
+msgid ""
+"Binding services (e.g., JBoss Web) to all interfaces. This can be done like "
+"this: <screen>./run.sh -b 0.0.0.0 -c all</screen> However, doing this will "
+"not cause JGroups to bind to all interfaces! Instead , JGroups will bind to "
+"the machine's default interface. See the Transport Protocols section for how "
+"to tell JGroups to receive or send on all interfaces, if that is what you "
+"really want."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:888
+#, no-c-format
+msgid ""
+"Binding services (e.g., JBoss Web) to all interfaces, but specify the "
+"JGroups interface: <screen>./run.sh -b 0.0.0.0 -Djgroups."
+"bind_addr=192.168.1.100 -c all</screen> Again, specifically setting the "
+"system property overrides the -b value."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:896
+#, no-c-format
+msgid "Using different interfaces for different channels:"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:898
+#, no-c-format
+msgid "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:903
+#, no-c-format
+msgid ""
+"This setting tells JGroups to ignore the <literal>jgroups.bind_addr</"
+"literal> system property, and instead use whatever is specfied in XML. You "
+"would need to edit the various XML configuration files to set the "
+"<literal>bind_addr</literal> to the desired interfaces."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:908
+#, no-c-format
+msgid "Isolating JGroups Channels"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:909
+#, no-c-format
+msgid ""
+"Within JBoss AS, there are a number of services that independently create "
+"JGroups channels -- 3 different JBoss Cache services (used for HttpSession "
+"replication, EJB3 SFSB replication and EJB3 entity replication) along with "
+"the general purpose clustering service called HAPartition that underlies "
+"most other JBossHA services."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:912
+#, no-c-format
+msgid ""
+"It is critical that these channels only communicate with their intended "
+"peers; not with the channels used by other services and not with channels "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:915
+#, no-c-format
+msgid ""
+"Whom a JGroups channel will communicate with is defined by its group name, "
+"multicast address, and multicast port, so isolating JGroups channels comes "
+"down to ensuring different channels use different values for the group name, "
+"multicast address and multicast port."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:918
+#, no-c-format
+msgid ""
+"To isolate JGroups channels for different services on the same set of AS "
+"instances from each other, you MUST change the group name and the multicast "
+"port. In other words, each channel must have its own set of values."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:921
+#, no-c-format
+msgid ""
+"For example, say we have a production cluster of 3 machines, each of which "
+"has an HAPartition deployed along with a JBoss Cache used for web session "
+"clustering. The HAPartition channels should not communicate with the JBoss "
+"Cache channels. They should use a different group name and multicast port. "
+"They can use the same multicast address, although they don't need to."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:924
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:927
+#, no-c-format
+msgid ""
+"For example, say we have a production cluster of 3 machines, each of which "
+"has an HAPartition deployed. On the same network there is also a QA cluster "
+"of 3 machines, which also has an HAPartition deployed. The HAPartition group "
+"name, multicast address, and multicast port for the production machines must "
+"be different from those used on the QA machines."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:933
+#, no-c-format
+msgid "Changing the Group Name"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:934
+#, no-c-format
+msgid ""
+"The group name for a JGroups channel is configured via the service that "
+"starts the channel. Unfortunately, different services use different "
+"attribute names for configuring this. For HAPartition and related services "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:937
+#, no-c-format
+msgid ""
+"Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss "
+"Cache services, we make it easy for you to create unique groups names simply "
+"by using the -g (a.k.a. –partition) switch when starting JBoss: <screen>./"
+"run.sh -g QAPartition -b 192.168.1.100 -c all</screen> This switch sets the "
+"jboss.partition.name system property, which is used as a component in the "
+"configuration of the group name in all the standard clustering configuration "
+"files. For example,"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:941
+#, no-c-format
+msgid ""
+"<![CDATA[<attribute name=\"ClusterName\">Tomcat-${jboss.partition.name:"
+"Cluster}</attribute>]]>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:947
+#, no-c-format
+msgid "Changing the multicast address and port"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:948
+#, no-c-format
+msgid ""
+"The -u (a.k.a. --udp) command line switch may be used to control the "
+"multicast address used by the JGroups channels opened by all standard AS "
+"services. <screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b "
+"192.168.1.100 -c all]]></screen> This switch sets the jboss.partition."
+"udpGroup system property, which you can see referenced in all of the "
+"standard protocol stack configs in JBoss AS:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:954
+#, no-c-format
+msgid ""
+"<![CDATA[<Config>\n"
+"<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\"\n"
+" ....]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:955
+#, no-c-format
+msgid ""
+"Unfortunately, setting the multicast ports is not so simple. As described "
+"above, by default there are four separate JGroups channels in the standard "
+"JBoss AS all configuration, and each should be given a unique port. There "
+"are no command line switches to set these, but the standard configuration "
+"files do use system properties to set them. So, they can be configured from "
+"the command line by using -D. For example,"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:958
+#, no-c-format
+msgid ""
+"/run.sh -u 230.1.2.3 -g QAPartition -Djboss.hapartition.mcast_port=12345 -"
+"Djboss.webpartition.mcast_port=23456 -Djboss.ejb3entitypartition."
+"mcast_port=34567 -Djboss.ejb3sfsbpartition.mcast_port=45678 -b 192.168.1.100 "
+"-c all"
+msgstr ""
+
+#. Tag: emphasis
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:960
+#, no-c-format
+msgid "Why isn't it sufficient to change the group name?"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:961
+#, no-c-format
+msgid ""
+"If channels with different group names share the same multicast address and "
+"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 ""
+
+#. Tag: emphasis
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:965
+#, no-c-format
+msgid "Why do I need to change the multicast port if I change the address?"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:966
+#, no-c-format
+msgid ""
+"It should be sufficient to just change the address, but there is a problem "
+"on several operating systems whereby packets addressed to a particular "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:972
+#, no-c-format
+msgid "JGroups Troubleshooting"
+msgstr ""
+
+#. Tag: emphasis
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:973
+#, no-c-format
+msgid "Nodes do not form a cluster"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:975
+#, no-c-format
+msgid ""
+"Make sure your machine is set up correctly for IP multicast. There are 2 "
+"test programs that can be used to detect this: McastReceiverTest and "
+"McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> "
+"directory and start McastReceiverTest, for example:"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:977
+#, no-c-format
+msgid ""
+"java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr "
+"224.10.10.10 -port 5555"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:980
+#, no-c-format
+msgid "Then in another window start <literal>McastSenderTest</literal>:"
+msgstr ""
+
+#. Tag: screen
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:982
+#, no-c-format
+msgid ""
+"java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr "
+"224.10.10.10 -port 5555"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:985
+#, no-c-format
+msgid ""
+"If you want to bind to a specific network interface card (NIC), use "
+"<literal>-bind_addr 192.168.0.2</literal>, where 192.168.0.2 is the IP "
+"address of the NIC to which you want to bind. Use this parameter in both the "
+"sender and the receiver."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:988
+#, no-c-format
+msgid ""
+"You should be able to type in the <literal>McastSenderTest</literal> window "
+"and see the output in the <literal>McastReceiverTest</literal> window. If "
+"not, try to use -ttl 32 in the sender. If this still fails, consult a system "
+"administrator to help you setup IP multicast correctly, and ask the admin to "
+"make sure that multicast will work on the interface you have chosen or, if "
+"the machines have multiple interfaces, ask to be told the correct interface. "
+"Once you know multicast is working properly on each machine in your cluster, "
+"you can repeat the above test to test the network, putting the sender on one "
+"machine and the receiver on another."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:995
+#, no-c-format
+msgid "Causes of missing heartbeats in FD"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:996
+#, no-c-format
+msgid ""
+"Sometimes a member is suspected by FD because a heartbeat ack has not been "
+"received for some time T (defined by timeout and max_tries). This can have "
+"multiple reasons, e.g. in a cluster of A,B,C,D; C can be suspected if (note "
+"that A pings B, B pings C, C pings D and D pings A):"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:1002
+#, no-c-format
+msgid ""
+"B or C are running at 100% CPU for more than T seconds. So even if C sends a "
+"heartbeat ack to B, B may not be able to process it because it is at 100%"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:1007
+#, no-c-format
+msgid "B or C are garbage collecting, same as above."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:1012
+#, no-c-format
+msgid "A combination of the 2 cases above"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:1017
+#, no-c-format
+msgid ""
+"The network loses packets. This usually happens when there is a lot of "
+"traffic on the network, and the switch starts dropping packets (usually "
+"broadcasts first, then IP multicasts, TCP packets last)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JBoss_Cache_JGroups.xml:1022
+#, no-c-format
+msgid ""
+"B or C are processing a callback. Let's say C received a remote method call "
+"over its channel and takes T+1 seconds to process it. During this time, C "
+"will not process any other messages, including heartbeats, and therefore B "
+"will not receive the heartbeat ack and will suspect C."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JMS.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JMS.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JMS.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,510 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:5
+#, no-c-format
+msgid "Clustered JMS Services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:7
+#, no-c-format
+msgid ""
+"JBoss AS 3.2.4 and above support high availability JMS (HA-JMS) services in "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:12
+#, no-c-format
+msgid ""
+"If you are willing to configure HA-JMS yourself, you can get it to work with "
+"earlier versions of JBoss AS. We have a customer who uses HA-JMS "
+"successfully in JBoss AS 3.0.7. Please contact JBoss support for more "
+"questions."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:16
+#, no-c-format
+msgid ""
+"The HA-JMS in JBoss AS 4.2.2 and earlier is based on the JBoss MQ messaging "
+"product. In later releases of the AS, JBoss MQ will be replaced by the newer "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:25
+#, no-c-format
+msgid "High Availability Singleton Fail-over"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:26
+#, no-c-format
+msgid ""
+"The JBoss HA-JMS service (i.e., message queues topics and supporting "
+"services) only runs on a single node (i.e., the master node) in the cluster "
+"at any given time. If that node fails, the cluster simply elects another "
+"node to run the JMS service, and the queues, topics and supporting services "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:28
+#, no-c-format
+msgid ""
+"While you cannot load balance HA-JMS queues (there is only one master node "
+"that runs the queues), you can load balance the MDBs that process messages "
+"from those queues (see <xref linkend=\"clustering-jms-loadbalanced\"/>)."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:33
+#, no-c-format
+msgid "Server Side Configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:35
+#, no-c-format
+msgid ""
+"The biggest configuration difference between HA-JMS in the all configuration "
+"and the non-HA version found in the default configuration is the location of "
+"most configuration files. For HA-JMS, most configuration files are found in "
+"the deploy-hasingleton/jms directory, not in deploy/jms. Your queues and "
+"topics must be deployed in deploy-hasingleton (or a subdirectory of it like "
+"deploy-hasingleton/jms.) Application components that act as clients to HA-"
+"JMS (e.g., MDBs and other JMS clients) do not need to be deployed in deploy-"
+"hasingleton. They should only be deployed there if you only want them "
+"running on one node in the cluster at a time."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:38
+#, no-c-format
+msgid ""
+"To use the singleton fail-over HA-JMS service, you must configure JMS "
+"services identically on all nodes in the cluster. That includes all JMS "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:44
+#, no-c-format
+msgid ""
+"The JMS server is configured to persist its data in the <literal>DefaultDS</"
+"literal>. By default, that is the embedded HSQLDB. However, for the HA-JMS "
+"service fail-over to work, the newly started HA-JMS server needs to be able "
+"to find the data persisted by the old server. That's not likely to happen if "
+"the data is persisted in files written by the old servers' HSQLDB. In almost "
+"any cluster environments, all nodes need to persist data against a shared "
+"database. So, the first thing to do before you start clustered JMS is to "
+"setup a shared database for JMS. You need to do the following:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:50
+#, no-c-format
+msgid ""
+"Configure <literal>DefaultDS</literal> to point to the database server of "
+"your choice. That is to replace the <literal>deploy/hsqlsb-ds.xml</literal> "
+"file with the <literal>xxx-ds.xml</literal> file in the <literal>docs/"
+"examples/jca</literal> directory, where <literal>xxx</literal> is the name "
+"of the target shared database (e.g., <literal>mysql-ds.xml</literal>)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:57
+#, no-c-format
+msgid ""
+"Replace the <literal>hsqldb-jdbc2-service.xml</literal> file under the "
+"<literal>server/all/deploy-hasingleton/jms</literal> directory with one "
+"tuned to the specific database. For example if you use MySQL the file is "
+"<literal>mysql-jdbc2-service.xml</literal>. Configuration files for a number "
+"of RDBMS are bundled with the JBoss AS distribution. They can be found under "
+"<literal>docs/examples/jms</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:66
+#, no-c-format
+msgid ""
+"There is no need to replace the <literal>hsqldb-jdbc-state-service.xml</"
+"literal> file under the <literal>server/all/deploy-hasingleton/jms</literal> "
+"directory. Despite the <literal>hsql</literal> in its name, it works with "
+"all SQL92 compliant databases, including HSQL, MySQL, SQL Server, and more. "
+"It automatically uses the <literal>DefaultDS</literal> for storage, which we "
+"configured above."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:77
+#, no-c-format
+msgid "Non-MDB HA-JMS Clients"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:79
+#, no-c-format
+msgid ""
+"The HA-JMS client is different from regular JMS clients in two important "
+"aspects."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:83
+#, no-c-format
+msgid ""
+"The HA-JMS client must look up JMS connection factories as well as queues "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:91
+#, no-c-format
+msgid ""
+"If the client is a J2EE component (session bean or web application) running "
+"inside the AS, the lookup via HA-JNDI can be configured using the "
+"component's deployment descriptors: In the standard deployment descriptor "
+"(ejb-jar.xml or web.xml):"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JMS.xml:99
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<resource-ref>\n"
+" <res-ref-name>jms/ConnectionFactory</res-ref-name>\n"
+" <res-type>javax.jms.QueueConnectionFactory</res-type>\n"
+" <res-auth>Container</res-auth>\n"
+"</resource-ref>\n"
+" \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/Queue</res-ref-name>\n"
+" <res-type>javax.jms.Queue</res-type>\n"
+" <res-auth>Container</res-auth>\n"
+"</resource-ref>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:101
+#, no-c-format
+msgid "And in the JBoss-specific descriptor (jboss.xml or jboss-web.xml):"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JMS.xml:105
+#, no-c-format
+msgid ""
+"<![CDATA[ \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/ConnectionFactory</res-ref-name>\n"
+" <!-- Use the JMS Resource Adapter, let it deal\n"
+" with knowing where the JMS server is -->\n"
+" <jndi-name>java:/JmsXA</jndi-name>\n"
+" </resource-ref>\n"
+" \n"
+"<resource-ref>\n"
+" <res-ref-name>jms/Queue</res-ref-name>\n"
+" <!-- Use HA-JNDI so we can find the queue on any node -->\n"
+" <jndi-name>jnp://localhost:1100/queue/A</jndi-name>\n"
+"</resource-ref>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:110
+#, no-c-format
+msgid ""
+"The HA-JMS client must deal with exceptions that will occur on the JMS "
+"connection if server failover occurs. Unlike, for example, clustered EJB "
+"proxies, the JMS connection object does not include automatic failover "
+"logic. If the HA-JMS service fails over to a different master node, all "
+"client operations on the current connection will fail with a JMSException. "
+"To deal with this:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:118
+#, no-c-format
+msgid ""
+"If the client is running inside the application server, the client should "
+"obtain the ConnectionFactory by looking up java:/JmsXAin JNDI. This will "
+"find the JBoss JMS Resource Adapter; the resource adapter will handle the "
+"task of detecting server failover and reconnecting to the new server when it "
+"starts."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:122
+#, no-c-format
+msgid ""
+"For clients outside the application server, the best approach is to register "
+"an ExceptionListener with the connection; the listener will get a callback "
+"if there is an exception on the connection. The callback should then handle "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JMS.xml:128
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"package com.test.hajms.client;\n"
+"\n"
+"import javax.naming.InitialContext;\n"
+"import javax.jms.ConnectionFactory;\n"
+"import javax.jms.Destination;\n"
+"import javax.jms.Connection;\n"
+"import javax.jms.Session;\n"
+"import javax.jms.MessageProducer;\n"
+"import javax.jms.Message;\n"
+"import javax.jms.ExceptionListener;\n"
+"import javax.jms.JMSException;\n"
+"import javax.jms.DeliveryMode;\n"
+"\n"
+"import org.apache.commons.logging.Log;\n"
+"import org.apache.commons.logging.LogFactory;\n"
+" \n"
+"public class FailoverJMSClient\n"
+"{\n"
+"private static final Log log = LogFactory.getLog(FailoverJMSClient.class);\n"
+"\n"
+"public static final int NUM_RETRIES = 3;\n"
+"\n"
+"volatile boolean doSend = true;\n"
+"ConnectionFactory connectionFactory;\n"
+"Destination queue;\n"
+"Connection connection;\n"
+"Session session;\n"
+"MessageProducer producer;\n"
+"\n"
+"\n"
+"public static void main(String[] args) throws Exception\n"
+"{\n"
+"FailoverJMSClient jmsClient = new FailoverJMSClient();\n"
+"jmsClient.setUpJMS();\n"
+"jmsClient.sendMessages();\n"
+"}\n"
+"\n"
+"\n"
+"public boolean setUpJMS()\n"
+"{\n"
+"InitialContext ic;\n"
+"try\n"
+"{\n"
+"// assume jndi.properties is configured for HA-JNDI\n"
+"ic = new InitialContext();\n"
+"connectionFactory = (ConnectionFactory)ic.lookup(\"ConnectionFactory\");\n"
+"queue = (Destination)ic.lookup(\"queue/FailoverTestQueue\");\n"
+"connection = connectionFactory.createConnection();\n"
+"try\n"
+"{\n"
+"log.debug(\"Connection created ...\");\n"
+"\n"
+"// KEY - register for exception callbacks\n"
+"connection.setExceptionListener(new ExceptionListenerImpl());\n"
+"\n"
+"session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);\n"
+"log.debug(\"Session created ...\");\n"
+"producer = session.createProducer(queue);\n"
+"\n"
+"producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);\n"
+"log.debug(\"Producer created ...\");\n"
+"\n"
+"return true;\n"
+"}\n"
+"catch (Exception e)\n"
+"{\n"
+"// We failed so close the connection\n"
+"try\n"
+"{\n"
+"connection.close();\n"
+"}\n"
+"catch (JMSException ignored)\n"
+"{\n"
+"// Pointless\n"
+"}\n"
+"// Rethrow the initial problem to where we will log it\n"
+"throw e;\n"
+"} \n"
+"finally\n"
+"{\n"
+"// And close the initial context\n"
+"// We don't want to wait for the garbage collector to close it\n"
+"// otherwise we'll have useless hanging network connections\n"
+"ic.close();\n"
+"}\n"
+"}\n"
+"catch (Exception e)\n"
+"{\n"
+"log.error(\"Error setting up JMS\", e);\n"
+"return false;\n"
+"}\n"
+"}\n"
+"\n"
+"public void sendMessages()\n"
+"{\n"
+"int cnt = 0;\n"
+"while(doSend)\n"
+"{\n"
+"try\n"
+"{\n"
+"Thread.sleep(100);\n"
+"\n"
+"Message m = session.createObjectMessage(new Integer(cnt++));\n"
+"producer.send(m);\n"
+"\n"
+"log.trace(\"message \" + cnt + \" sent\");\n"
+"\n"
+"}\n"
+"catch(Exception e)\n"
+"{\n"
+"cnt--;\n"
+"log.error(e.getMessage());\n"
+"}\n"
+"}\n"
+"}\n"
+"\n"
+"\n"
+"\n"
+"private class ExceptionListenerImpl implements ExceptionListener\n"
+"{\n"
+"public void onException(JMSException e)\n"
+"{\n"
+" \n"
+"for(int i = 0; i < NUM_RETRIES; i++)\n"
+" {\n"
+" log.warn(\"Connection has problems, trying to re-create it, "
+"attempt \" +\n"
+" (i + 1) + \" ...\");\n"
+" \n"
+" try \n"
+" {\n"
+" connection.close(); // unregisters the ExceptionListener\n"
+" }\n"
+" catch(Exception e2) {\n"
+" // I will get an Exception anyway, since the connection to "
+"the \n"
+" //server is broken, but close() frees up resources associated \n"
+" // with the connection\n"
+" }\n"
+" \n"
+" boolean setupOK = setUpJMS();\n"
+" \n"
+" if (setupOK)\n"
+" {\n"
+" log.info(\"Connection re-established\");\n"
+" return;\n"
+" }\n"
+" else\n"
+" {\n"
+" log.warn(\"Re-creating connection failed, retrying ...\");\n"
+" }\n"
+" }\n"
+" \n"
+" log.error(\"Cannot re-establish connection, giving up ...\");\n"
+" doSend = false;\n"
+" }\n"
+" }\n"
+"}\n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:132
+#, no-c-format
+msgid "MDBs and HA-JMS Failover"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:133
+#, no-c-format
+msgid ""
+"When you deploy an MDB in JBoss, JBoss' MDB container handles for you all "
+"issues associated with finding the cluster singleton HA-JMS server and with "
+"reconnecting to it if it fails over."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JMS.xml:143
+#, no-c-format
+msgid "Load Balanced HA-JMS MDBs"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:144
+#, no-c-format
+msgid ""
+"While the HA-JMS queues and topics only run on a single node at a time, MDBs "
+"on multiple nodes can receive and process messages from the HA-JMS master "
+"node. The contested queues and topics result in load balancing behavior for "
+"MDBs. To enable loading balancing for MDBs, you can specify a receiver for "
+"the queue. The receiver records which node is waiting for a message and in "
+"which order the messages should be processed. JBoss provides three receiver "
+"implementations."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:151
+#, no-c-format
+msgid ""
+"The <literal>org.jboss.mq.server.ReceiversImpl</literal> is the default "
+"implementation using a <literal>HashSet</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:155
+#, no-c-format
+msgid ""
+"The <literal>org.jboss.mq.server.ReceiversImplArrayList</literal> is the "
+"implementation using an <literal>ArrayList</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:159
+#, no-c-format
+msgid ""
+"The <literal>org.jboss.mq.server.ReceiversImplLinkedList</literal> is the "
+"implementation using a <literal>LinkedList</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JMS.xml:163
+#, no-c-format
+msgid ""
+"You can specify the receiver implementation class name as an attribute in "
+"the MBean that defines the permanent JMS <literal>Queue</literal> or "
+"<literal>DestinationManager</literal> on each node. For best load balancing "
+"performance, we suggest you to use the <literal>ReceiversImplArrayList</"
+"literal> or <literal>ReceiversImplLinkedList</literal> implementations due "
+"to an undesirable implementation detail of <literal>HashSet</literal> in the "
+"JVM."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JNDI.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JNDI.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Clustering_Guide_JNDI.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,783 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:5
+#, no-c-format
+msgid "Clustered JNDI Services"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:6
+#, no-c-format
+msgid ""
+"JNDI is one of the most important services provided by the application "
+"server. The JBoss HA-JNDI (High Availability JNDI) service brings the "
+"following features to JNDI:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:10
+#, no-c-format
+msgid ""
+"Transparent failover of naming operations. If an HA-JNDI naming Context is "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:15
+#, no-c-format
+msgid ""
+"Load balancing of naming operations. An HA-JNDI naming Context will "
+"automatically load balance its requests across all the HA-JNDI servers in "
+"the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:20
+#, no-c-format
+msgid "Automatic client discovery of HA-JNDI servers (using multicast)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:25
+#, no-c-format
+msgid ""
+"Unified view of JNDI trees cluster-wide. Client can connect to the HA-JNDI "
+"service running on any node in the cluster and find objects bound in JNDI on "
+"any other node. This is accomplished via two mechanisms:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:33
+#, no-c-format
+msgid ""
+"Cross-cluster lookups. A client can perform a lookup and the server side HA-"
+"JNDI service has the ability to find things bound in regular JNDI on any "
+"node in the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:37
+#, no-c-format
+msgid ""
+"A replicated cluster-wide context tree. An object bound into the HA-JNDI "
+"service will be replicated around the cluster, and a copy of that object "
+"will be available in-VM on each node in the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:46
+#, no-c-format
+msgid ""
+"JNDI is a key component for many other interceptor-based clustering "
+"services: those services register themselves with the JNDI so that the "
+"client can lookup their proxies and make use of their services. HA-JNDI "
+"completes the picture by ensuring that clients have a highly-available means "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:51
+#, no-c-format
+msgid ""
+"If an EJB is not configured as clustered, looking up the EJB via HA-JNDI "
+"does not somehow result in the addition of clustering capabilities (load "
+"balancing of EJB calls, transparent failover, state replication) to the EJB."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:56
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:66
+#, no-c-format
+msgid "How it works"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:67
+#, no-c-format
+msgid ""
+"The JBoss client-side HA-JNDI naming Context is based on the client-side "
+"interceptor architecture. The client obtains an HA-JNDI proxy object (via "
+"the InitialContext object) and invokes JNDI lookup services on the remote "
+"server through the proxy. The client specifies that it wants an HA-JNDI "
+"proxy by configuring the naming properties used by the InitialContext "
+"object. This is covered in detail in the “Client Configuration” section. "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:70
+#, no-c-format
+msgid ""
+"On the server side, he the HA-JNDI service maintains a cluster-wide context "
+"tree. The cluster wide tree is always available as long as there is one node "
+"left in the cluster. Each node in the cluster also maintains its own local "
+"JNDI context tree. The HA-JNDI service on that node is able to find objects "
+"bound into the local JNDI context tree. An application can bind its objects "
+"to either tree. The design rationale for this architecture is as follows:"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:75
+#, no-c-format
+msgid ""
+"It avoids migration issues with applications that assume that their JNDI "
+"implementation is local. This allows clustering to work out-of-the-box with "
+"just a few tweaks of configuration files."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:81
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:86
+#, no-c-format
+msgid ""
+"Designing it in this way makes the HA-JNDI service an optional service since "
+"all underlying cluster code uses a straight new <literal>InitialContext()</"
+"literal> to lookup or create bindings."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:92
+#, no-c-format
+msgid ""
+"On the server side, a naming <literal>Context</literal> obtained via a call "
+"to new <literal>InitialContext()</literal> will be bound to the local-only, "
+"non-cluster-wide JNDI Context (this is actually basic JNDI). So, all EJB "
+"homes and such will not be bound to the cluster-wide JNDI Context, but "
+"rather, each home will be bound into the local JNDI."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:95
+#, no-c-format
+msgid ""
+"When a remote client does a lookup through HA-JNDI, HA-JNDI will delegate to "
+"the local JNDI Context when it cannot find the object within the global "
+"cluster-wide Context. The detailed lookup rule is as follows."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:100
+#, no-c-format
+msgid "If the binding is available in the cluster-wide JNDI tree, return it."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:103
+#, no-c-format
+msgid ""
+"If the binding is not in the cluster-wide tree, delegate the lookup query to "
+"the local JNDI service and return the received answer if available."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:106
+#, no-c-format
+msgid ""
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:109
+#, no-c-format
+msgid ""
+"If no local JNDI service owns such a binding, a "
+"<literal>NameNotFoundException</literal> is finally raised."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:113
+#, no-c-format
+msgid ""
+"In practice, objects are rarely bound in the cluster-wide JNDI tree; rather "
+"they are bound in the local JNDI tree. For example, when EJBs are deployed, "
+"their proxies are always bound in local JNDI, not HA-JNDI. So, an EJB home "
+"lookup done through HA-JNDI will always be delegated to the local JNDI "
+"instance."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:117 Clustering_Guide_JNDI.xml:124
+#: Clustering_Guide_JNDI.xml:130
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:118
+#, no-c-format
+msgid ""
+"If different beans (even of the same type, but participating in different "
+"clusters) use the same JNDI name, this means that each JNDI server will have "
+"a logically different \"target\" bound (JNDI on node 1 will have a binding "
+"for bean A and JNDI on node 2 will have a binding, under the same name, for "
+"bean B). Consequently, if a client performs a HA-JNDI query 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! So, it is always best practice to ensure "
+"that across the cluster different names are used for logically different "
+"bindings."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:125
+#, no-c-format
+msgid ""
+"You cannot currently use a non-JNP JNDI implementation (i.e. LDAP) for your "
+"local JNDI implementation if you want to use HA-JNDI. However, you can use "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:131
+#, no-c-format
+msgid ""
+"If a binding is only made available on a few nodes in the cluster (for "
+"example because a bean is only deployed on a small subset of nodes in the "
+"cluster), the probability that a lookup will hit a HA-JNDI server that does "
+"not own this binding is higher and thus the lookup will need to be forwarded "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:139
+#, no-c-format
+msgid ""
+"So, an EJB home lookup through HA-JNDI, will always be delegated to the "
+"local JNDI instance. If different beans (even of the same type, but "
+"participating in different clusters) use the same JNDI name, it means that "
+"each JNDI server will have a different \"target\" bound (JNDI on node 1 will "
+"have a binding for bean A and JNDI on node 2 will have a binding, under the "
+"same name, for bean B). Consequently, if a client performs a HA-JNDI query "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:147
+#, no-c-format
+msgid ""
+"You cannot currently use a non-JNP JNDI implementation (i.e. LDAP) for your "
+"local JNDI implementation if you want to use HA-JNDI. However, you can use "
+"JNDI federation using the <literal>ExternalContext</literal> MBean to bind "
+"non-JBoss JNDI trees into the JBoss JNDI namespace. Furthermore, nothing "
+"prevents you though of using one centralized JNDI server for your whole "
+"cluster and scrapping HA-JNDI and JNP."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:154
+#, no-c-format
+msgid ""
+"If a binding is only made available on a few nodes in the cluster (for "
+"example because a bean is only deployed on a small subset of nodes in the "
+"cluster), the probability to lookup a HA-JNDI server that does not own this "
+"binding is higher and the lookup will need to be forwarded 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 ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:166
+#, no-c-format
+msgid "Client configuration"
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:168
+#, no-c-format
+msgid "For clients running inside the application server"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:169
+#, no-c-format
+msgid ""
+"If you want to access HA-JNDI from inside the application server, you must "
+"explicitly get an InitialContext by passing in JNDI properties. The "
+"following code shows how to create a naming Context bound to HA-JNDI:"
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JNDI.xml:172
+#, no-c-format
+msgid ""
+"Properties p = new Properties(); \n"
+" p.put(Context.INITIAL_CONTEXT_FACTORY, \n"
+" \"org.jnp.interfaces.NamingContextFactory\"); \n"
+" p.put(Context.URL_PKG_PREFIXES, \"jboss.naming:org.jnp.interfaces"
+"\"); \n"
+" p.put(Context.PROVIDER_URL, \"localhost:1100\"); // HA-JNDI port. \n"
+" return new InitialContext(p);"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:173
+#, no-c-format
+msgid ""
+"The Context.PROVIDER_URL property points to the HA-JNDI service configured "
+"in the HANamingService MBean (see the section called “JBoss configuration”)."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:176
+#, no-c-format
+msgid ""
+"Do not attempt to simplify things by placing a jndi.properties file in your "
+"deployment or by editing the AS's conf/jndi.properties file. Doing either "
+"will almost certainly break things for your application and quite possibly "
+"across the application server. If you want to externalize your client "
+"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 ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:183
+#, no-c-format
+msgid "For clients running outside the application server"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:185
+#, no-c-format
+msgid ""
+"The JNDI client needs to be aware of the HA-JNDI cluster. You can pass a "
+"list of JNDI servers (i.e., the nodes in the HA-JNDI cluster) to the "
+"<literal>java.naming.provider.url</literal> JNDI setting in the "
+"<literal>jndi.properties</literal> file. Each server node is identified by "
+"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 ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JNDI.xml:187
+#, no-c-format
+msgid ""
+"java.naming.provier.url=server1:1100,server2:1100,server3:1100,server4:1100"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:188
+#, no-c-format
+msgid ""
+"When initialising, the JNP client code will try to get in touch with each "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:192
+#, no-c-format
+msgid ""
+"There is no load balancing behavior in the JNP client lookup process itself. "
+"It just goes through the provider lists and uses the first available server "
+"to obtain the stub. The HA-JNDI provider list only needs to contain a subset "
+"of HA-JNDI nodes in the cluster."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:195
+#, no-c-format
+msgid ""
+"The downloaded smart proxy contains the list of currently running nodes and "
+"the logic to load balance naming requests and to fail-over to another node "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:199
+#, no-c-format
+msgid ""
+"If the property string java.naming.provider.url is empty or if all servers "
+"it mentions are not reachable, the JNP client will try to discover a HA-JNDI "
+"server through a multicast call on the network (auto-discovery). See the "
+"section called “JBoss configuration” on how to configure auto-discovery on "
+"the JNDI server nodes. Through auto-discovery, the client might be able to "
+"get a valid HA-JNDI server node without any configuration. Of course, for "
+"auto-discovery to work, the network segment(s) between the client and the "
+"server cluster must be configured to propagate such multicast datagrams."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:203
+#, no-c-format
+msgid ""
+"By default the auto-discovery feature uses multicast group address 230.0.0.4 "
+"and port1102."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:205
+#, no-c-format
+msgid ""
+"In addition to the <literal>java.naming.provider.url</literal> property, you "
+"can specify a set of other properties. The following list shows all "
+"clustering-related client side properties you can specify when creating a "
+"new InitialContext. (All of the standard, non-clustering-related environment "
+"properties used with regular JNDI are also available.)"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:208
+#, no-c-format
+msgid ""
+"<literal>java.naming.provider.url</literal>: Provides a list of IP addresses "
+"and port numbers for HA-JNDI provider nodes in the cluster. The client tries "
+"those providers one by one and uses the first one that responds."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:213
+#, no-c-format
+msgid ""
+"<literal>jnp.disableDiscovery</literal>: When set to <literal>true</"
+"literal>, this property disables the automatic discovery feature. Default is "
+"<literal>false</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:218
+#, no-c-format
+msgid ""
+"<literal>jnp.partitionName</literal>: In an environment where multiple HA-"
+"JNDI services bound to distinct clusters (a.k.a. partitions), are running, "
+"this property allows you to ensure that your client only accepts automatic-"
+"discovery responses from servers in the desired partition. If you do not use "
+"the automatic discovery feature (i.e. jnp.disableDiscovery is true), this "
+"property is not used. By default, this property is not set and the automatic "
+"discovery select the first HA-JNDI server that responds, irregardless of the "
+"cluster partition name."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:221
+#, no-c-format
+msgid ""
+"<literal>jnp.discoveryTimeout</literal>: Determines how much time the "
+"context will wait for a response to its automatic discovery packet. Default "
+"is 5000 ms."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:225
+#, no-c-format
+msgid ""
+"<literal>jnp.discoveryGroup</literal>: Determines which multicast group "
+"address is used for the automatic discovery. Default is 230.0.0.4. Must "
+"match the value of the AutoDiscoveryAddress configured on the server side HA-"
+"JNDI service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:228
+#, no-c-format
+msgid ""
+"<literal>jnp.discoveryPort</literal>: Determines which multicast group port "
+"is used for the automatic discovery. Default is 1102. Must match the value "
+"of the AutoDiscoveryPort configured on the server side HA-JNDI service."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:231
+#, no-c-format
+msgid ""
+"<literal>jnp.discoveryTTL</literal>: specifies the TTL (time-to-live) for "
+"autodiscovery IP multicast packets. This value represents the number of "
+"network hops a multicast packet can be allowed to propagate before "
+"networking equipment should drop the packet. Despite its name, it does not "
+"represent a unit of time."
+msgstr ""
+
+#. Tag: title
+#: Clustering_Guide_JNDI.xml:242
+#, no-c-format
+msgid "JBoss configuration"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:243
+#, no-c-format
+msgid ""
+"The <literal>cluster-service.xml</literal> file in the <literal>all/deploy</"
+"literal> directory includes the following MBean to enable HA-JNDI services."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JNDI.xml:245
+#, no-c-format
+msgid ""
+"<mbean code=\"org.jboss.ha.jndi.HANamingService\" \n"
+" name=\"jboss:service=HAJNDI\"> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" \n"
+" proxy-type=\"attribute\">jboss:service=${jboss.partition."
+"name:DefaultPartition}</depends> \n"
+" \n"
+"<mbean>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:246
+#, no-c-format
+msgid ""
+"You can see that this MBean depends on the <literal>DefaultPartition</"
+"literal> MBean defined above it (discussed earlier in this chapter). In "
+"other configurations, you can put that element in the <literal>jboss-service."
+"xml</literal> file or any other JBoss configuration files in the <literal>/"
+"deploy</literal> directory to enable HA-JNDI services. The available "
+"attributes for this MBean are listed below."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:252
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">Cluster Partition</emphasis> is a required attribute "
+"to inject the HAPartition service that HA-JNDI uses for intra-cluster "
+"communication."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:255
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">BindAddress</emphasis> is an optional attribute to "
+"specify the address to which the HA-JNDI server will bind waiting for JNP "
+"clients. Only useful for multi-homed computers. The default value is the "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:258
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">Port</emphasis> is an optional attribute to specify "
+"the port to which the HA-JNDI server will bind waiting for JNP clients. The "
+"default value is <literal>1100</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:263
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">Backlog</emphasis> is an optional attribute to "
+"specify the backlog value used for the TCP server socket waiting for JNP "
+"clients. The default value is <literal>50</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:268
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">RmiPort</emphasis> determines which port the server "
+"should use to communicate with the downloaded stub. This attribute is "
+"optional. The default value is 1101. If no value is set, the server "
+"automatically assigns a RMI port."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:271
+#, no-c-format
+msgid ""
+"<literal>DiscoveryDisabled</literal> is a boolean flag that disables "
+"configuration of the auto discovery multicast listener."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:277
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">AutoDiscoveryAddress</emphasis> is an optional "
+"attribute to specify the multicast address to listen to for JNDI automatic "
+"discovery. The default value is the value of the jboss.partition.udpGroup "
+"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 ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:280
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">AutoDiscoveryGroup</emphasis> is an optional "
+"attribute to specify the multicast group to listen to for JNDI automatic "
+"discovery.. The default value is <literal>1102</literal>."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:286
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">AutoDiscoveryBindAddress</emphasis> sets the "
+"interface on which HA-JNDI should listen for auto-discovery request packets. "
+"If this attribute is not specified and a <literal>BindAddress</literal> is "
+"specified, the <literal>BindAddress</literal> will be used.."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:289
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">AutoDiscoveryTTL</emphasis> specifies the TTL (time-"
+"to-live) for autodiscovery IP multicast packets. This value represents the "
+"number of network hops a multicast packet can be allowed to propagate before "
+"networking equipment should drop the packet. Despite its name, it does not "
+"represent a unit of time."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:292
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">LoadBalancePolicy</emphasis> specifies the class "
+"name of the LoadBalancePolicyimplementation that should be included in the "
+"client proxy. See the earlier section on “Load-Balancing Policies” for "
+"details."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:297
+#, no-c-format
+msgid ""
+"<emphasis role=\"bold\">LookupPool</emphasis> specifies the thread pool "
+"service used to control the bootstrap and auto discovery lookups."
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:302
+#, no-c-format
+msgid ""
+"The full default configuration of the <literal>HANamingService</literal> "
+"MBean is as follows."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JNDI.xml:303
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+" <mbean code=\"org.jboss.ha.jndi.HANamingService\" \n"
+" name=\"jboss:service=HAJNDI\"> \n"
+" <!-- We now inject the partition into the HAJNDI service instead \n"
+" of requiring that the partition name be passed --> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" \n"
+" proxy-type=\"attribute\">jboss:service=${jboss.partition.name:"
+"DefaultPartition}</depends> \n"
+" <!-- Bind address of bootstrap and HA-JNDI RMI endpoints --> \n"
+" <attribute name=\"BindAddress\">${jboss.bind.address}</attribute> \n"
+" <!-- Port on which the HA-JNDI stub is made available --> \n"
+" <attribute name=\"Port\">1100</attribute> \n"
+" <!-- RmiPort to be used by the HA-JNDI service once bound. 0 => "
+"auto. --> \n"
+" <attribute name=\"RmiPort\">1101</attribute> \n"
+" <!-- Accept backlog of the bootstrap socket --> \n"
+" <attribute name=\"Backlog\">50</attribute> \n"
+" <!-- The thread pool service used to control the bootstrap and auto "
+"discovery lookups --> \n"
+" <depends optional-attribute-name=\"LookupPool\" \n"
+" proxy-type=\"attribute\">jboss.system:service=ThreadPool</"
+"depends> \n"
+" <!-- A flag to disable the auto discovery via multicast --> \n"
+" <attribute name=\"DiscoveryDisabled\">false</attribute> \n"
+" <!-- Set the auto-discovery bootstrap multicast bind address. If "
+"not \n"
+" specified and a BindAddress is specified, the BindAddress will be "
+"used. --> \n"
+" <attribute name=\"AutoDiscoveryBindAddress\">${jboss.bind.address}</"
+"attribute> \n"
+" <!-- Multicast Address and group port used for auto-discovery --> \n"
+" <attribute name=\"AutoDiscoveryAddress\">${jboss.partition."
+"udpGroup:230.0.0.4}</attribute> \n"
+" <attribute name=\"AutoDiscoveryGroup\">1102</attribute> \n"
+" <!-- The TTL (time-to-live) for autodiscovery IP multicast packets "
+"--> \n"
+" <attribute name=\"AutoDiscoveryTTL\">16</attribute> \n"
+" <!-- The load balancing policy for HA-JNDI --> \n"
+" <attribute name=\"LoadBalancePolicy\">org.jboss.ha.framework."
+"interfaces.RoundRobin</attribute> \n"
+" \n"
+" <!-- Client socket factory to be used for client-server \n"
+" RMI invocations during JNDI queries \n"
+" <attribute name=\"ClientSocketFactory\">custom</attribute> \n"
+" --> \n"
+" <!-- Server socket factory to be used for client-server \n"
+" RMI invocations during JNDI queries \n"
+" <attribute name=\"ServerSocketFactory\">custom</attribute> \n"
+" --> \n"
+" </mbean>]]>"
+msgstr ""
+
+#. Tag: para
+#: Clustering_Guide_JNDI.xml:304
+#, no-c-format
+msgid ""
+"It is possible to start several HA-JNDI services that use different "
+"clusters. This can be used, for example, if a node is part of many clusters. "
+"In this case, make sure that you set a different port or IP address for "
+"eachservices. For instance, if you wanted to hook up HA-JNDI to the example "
+"cluster you set up and change the binding port, the Mbean descriptor would "
+"look as follows."
+msgstr ""
+
+#. Tag: programlisting
+#: Clustering_Guide_JNDI.xml:307
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<mbean code=\"org.jboss.ha.jndi.HANamingService\" \n"
+" name=\"jboss:service=HAJNDI\"> \n"
+"\n"
+" <depends optional-attribute-name=\"ClusterPartition\" \n"
+" proxy-type=\"attribute\">jboss:service=MySpecialPartition</depends> \n"
+" <attribute name=\"Port\">56789</attribute> \n"
+"</mbean> ]]>"
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Deploy.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Deploy.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Deploy.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,176 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-10 06:03+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Deploy.xml:6
+#, no-c-format
+msgid "Deployment"
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:8
+#, no-c-format
+msgid ""
+"Deploying applications on JBoss AS is very easy. You just need to copy the "
+"application into the JBOSS_HOME/server/default/deploy directory. You can "
+"replace default with different server profiles such as all or minimal. We "
+"will cover those later in this chapter. JBoss AS constantly scans the deploy "
+"directory to pick up new applications or any changes to existing "
+"applications. So, you can \"hot deploy\" application on the fly while JBoss "
+"AS is still running."
+msgstr ""
+
+#. Tag: title
+#: Deploy.xml:11
+#, no-c-format
+msgid "Deployable Application Types"
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:13
+#, no-c-format
+msgid ""
+"You can deploy several different types of enterprise applications in JBoss "
+"AS:"
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:17
+#, no-c-format
+msgid ""
+"The WAR application archive (e.g., myapp.war) packages a Java EE web "
+"application in a JAR file. It contains servlet classes, view pages, "
+"libraries, and deployment descriptors such as web.xml, faces-config.xml, and "
+"jboss-web.xml etc."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:19
+#, no-c-format
+msgid ""
+"The EAR application archive (e.g., myapp.ear) packages a Java EE enterprise "
+"application in a JAR file. It typically contains a WAR file for the web "
+"module, JAR files for EJB modules, as well as deployment descriptors such as "
+"application.xml and jboss-app.xml etc."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:21
+#, no-c-format
+msgid ""
+"The SAR application archive (e.g., myservice.sar) packages a JBoss service "
+"in a JAR file. It is mostly used by JBoss internal services. Please see more "
+"in <xref linkend=\"The_JBoss_JMX_Microkernel\"/>."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:23
+#, no-c-format
+msgid ""
+"The *-ds.xml file defines connections to external databases. The data source "
+"can then be reused by all applications and services in JBoss AS via the "
+"internal JNDI."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:25
+#, no-c-format
+msgid ""
+"You can deploy XML files with MBean service definitions. If you have the "
+"appropriate JAR files available in the deploy or lib directories, the MBeans "
+"specified in the XML files will be started. This is the way how you start "
+"many JBoss AS internal services, such as the JMS queues."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:27
+#, no-c-format
+msgid ""
+"You can also deploy JAR files containing EJBs or other service objects "
+"directly in JBoss AS."
+msgstr ""
+
+#. Tag: title
+#: Deploy.xml:32
+#, no-c-format
+msgid "Exploded Deployment"
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:33
+#, no-c-format
+msgid ""
+"The WAR, EAR, and SAR deployment packages are really just JAR files with "
+"special XML deployment descriptors in directories like META-INF and WEB-INF. "
+"JBoss AS allows you to deploy those archives as expanded directories instead "
+"of JAR files. That allows you to make changes to web pages etc on the fly "
+"without re-deploying the entire application. If you do need to re-deploy the "
+"exploded directory without re-start the server, you can just \"touch\" the "
+"deployment descriptors (e.g., the WEB-INF/web.xml in a WAR and the META-INF/"
+"application.xml in an EAR) to update their timestamps."
+msgstr ""
+
+#. Tag: title
+#: Deploy.xml:39
+#, no-c-format
+msgid "Standard Server Configurations"
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:41
+#, no-c-format
+msgid ""
+"The JBoss Application Server ships with three server configurations. You can "
+"choose which configuration to start by passing the -c parameter to the "
+"server startup script. For instance, command run.sh -c all would start the "
+"server in the all configuration. Each configuration is contained in a "
+"directory named <literal> JBOSS_HOME/server/[config name]/</literal>. You "
+"can look into each server configuration's directory to see the default "
+"services, applications, and libraries supported in the configuration."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:44
+#, no-c-format
+msgid ""
+"The minimal configuration starts the core server container without any of "
+"the enterprise services. It is a good starting point if you want to build a "
+"customized version of JBoss AS that only contains the services you need."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:45
+#, no-c-format
+msgid ""
+"The default configuration is the mostly common used configuration for "
+"application developers. It supports the standard J2EE 1.4 and most of the "
+"Java EE 5.0 programming APIs (e.g., JSF and EJB3)."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:46
+#, no-c-format
+msgid ""
+"The all configuration is the default configuration with clustering support "
+"and other enterprise extensions."
+msgstr ""
+
+#. Tag: para
+#: Deploy.xml:50
+#, no-c-format
+msgid ""
+"The detailed services and APIs supported in each of those configurations "
+"will be discussed throughout this book."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/EJB3.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/EJB3.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/EJB3.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,1020 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:14+0000\n"
+"PO-Revision-Date: 2007-12-03 01:14+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: EJB3.xml:6
+#, no-c-format
+msgid "Enterprise Applications with EJB3 Services"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:10
+#, no-c-format
+msgid ""
+"EJB3 (Enterprise Java Bean 3.0) provides the core component model for Java "
+"EE 5 applications. An EJB3 bean is a managed component that is automatically "
+"wired to take advantage of all services the Java EE 5 server container "
+"provides, such as transaction, security, persistence, naming, dependency "
+"injection, etc. The managed component allows developers to focus on the "
+"business logic, and leave the cross-cutting concerns to the container as "
+"configurations. As an application developer, you need not create or destroy "
+"the components yourself. You only need to ask for an EJB3 bean from the Java "
+"EE container by its name, and then you can call its methods with all "
+"configured container services applied. You can get access to an EJB3 bean "
+"from either inside or outside of the Java EE container."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:12
+#, no-c-format
+msgid ""
+"JBoss AS 4.2 supports EJB3 out of the box. Note that JBoss AS 4.2 is a J2EE "
+"server, so it does not support the full EJB3 feature set."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:14
+#, no-c-format
+msgid ""
+"The details of the EJB3 component programming model is beyond the scope of "
+"this guide. Most EJB3 interfaces and annotations are part of the Java EE 5 "
+"standard and hence they are the same for all Java EE 5 compliant application "
+"servers. Interested readers should refer to the EJB3 specification or "
+"numerous EJB3 books to learn more about EJB3 programming."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:16
+#, no-c-format
+msgid ""
+"In this chapter, we only cover EJB3 configuration issues that are specific "
+"to the JBoss AS. For instance, we discuss the JNDI naming conventions for "
+"EJB3 components inside the JBoss AS, the optional configurations for the "
+"Hibernate persistence engine for entity beans, as well as custom options in "
+"the JBoss EJB3 deployer."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:19
+#, no-c-format
+msgid "Session Beans"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:21
+#, no-c-format
+msgid ""
+"Session beans are widely used to provide transactional services for local "
+"and remote clients. To write a session bean, you need an interface and an "
+"implementation class."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:23
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@Local\n"
+"public interface MyBeanInt {\n"
+" public String doSomething (String para1, int para2);\n"
+"}\n"
+"\n"
+"@Stateless\n"
+"public class MyBean implements MyBeanInt {\n"
+"\n"
+" public String doSomething (String para1, int para2) {\n"
+" ... implement the logic ...\n"
+" } \n"
+" \n"
+"} \n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:25
+#, no-c-format
+msgid ""
+"When you invoke a session bean method, the method execution is automatically "
+"managed by the transaction manager and the security manager in the server. "
+"You can specify the transactional or security properties for each method "
+"using annotations on the method. A session bean instance can be reused by "
+"many clients. Depending on whether the server maintains the bean's internal "
+"state between two clients, the session bean can be stateless or stateful. "
+"Depending on whether the bean has a remote business interface clients "
+"outside of the current JVM can call upon the EJB3 bean. All these are "
+"configurable via standard annotations on the beans. Note that the "
+"transactional or security properties are only active when the bean is called "
+"through a business interface."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:27
+#, no-c-format
+msgid ""
+"After you define a session bean, how does the client get a reference to it? "
+"As we discussed, the client does not create or destroy EJB3 components, it "
+"merely asks the server for a reference of an existing instance managed by "
+"the server. That is done via JNDI. In JBoss AS, the default local JNDI name "
+"for a session bean is dependent on the deployment packaging of the bean "
+"class."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:30
+#, no-c-format
+msgid ""
+"If the bean is deployed in a standalone JAR file in the <varname>JBOSS_DIST/"
+"default/deploy</varname> directory, the bean is accessible via local JNDI "
+"name <varname>MyBean/local</varname>, where <varname>MyBean</varname> is the "
+"implementation class name of the bean as we showed earlier. The \"local\" "
+"JNDI in JBoss AS means that the JNDI name is relative to <varname>java:comp/"
+"env/</varname>."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:31
+#, no-c-format
+msgid ""
+"If the JAR file containing the bean is packaged in an EAR file, the local "
+"JNDI name for the bean is <varname>myapp/MyBean/local</varname>, where "
+"<varname>myapp</varname> is the root name of the EAR archive file (e.g., "
+"<varname>myapp.ear</varname>, see later for the EAR packaging of EJB3 beans)."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:34
+#, no-c-format
+msgid ""
+"Of course, you should change <varname>local</varname> to <varname>remote</"
+"varname> if the bean interface is annotated with <varname>@Remote</varname> "
+"and the bean is accessed from outside of the server it is deployed on. Below "
+"is the code snippet to get a reference of the MyBean bean in a web "
+"application (e.g., in a servlet or a JSF backing bean) packaged in "
+"<varname>myapp.ear</varname>, and then invoke a managed method."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:36
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"try {\n"
+" InitialContext ctx = new InitialContext();\n"
+" MyBeanInt bean = (MyBeanInt) ctx.lookup(\"myapp/MyBean/local\");\n"
+"} catch (Exception e) {\n"
+" e.printStackTrace ();\n"
+"}\n"
+"\n"
+"... ...\n"
+"\n"
+"String result = bean.doSomething(\"have fun\", 1);\n"
+"\n"
+"... ...\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:38
+#, no-c-format
+msgid ""
+"What the client gets from the JNDI is essentially a \"stub\" or \"proxy\" of "
+"the bean instance. When the client invokes a method, the proxy figures out "
+"how to route the request to the server and marshal together the response."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:40
+#, no-c-format
+msgid ""
+"If you do not like the default JNDI names, you can always specify your own "
+"JNDI binding for any bean via the <varname>@LocalBinding</varname> "
+"annotation on the bean implementation class. The JNDI binding is always "
+"\"local\" under the <varname>java:comp/env/</varname> space. For instance, "
+"the following bean class definition results in the bean instances available "
+"under JNDI name <varname>java:comp/env/MyService/MyOwnName</varname>."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:42
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@Stateless\n"
+"@LocalBinding (jndiBinding=\"MyService/MyOwnName\")\n"
+"public class MyBean implements MyBeanInt {\n"
+"\n"
+" public String doSomething (String para1, int para2) {\n"
+" ... implement the logic ...\n"
+" } \n"
+" \n"
+"} \n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:45
+#, no-c-format
+msgid "Injecting EJB3 Beans into the Web Tier"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:46
+#, no-c-format
+msgid ""
+"Java EE 5 allows you to inject EJB3 bean instances directly into the web "
+"application via annotations without explicit JNDI lookup. This behavior is "
+"not yet supported in JBoss AS 4.2. However, the JBoss Enterprise Platform "
+"provides an integration framework called JBoss Seam. JBoss Seam brings "
+"EJB3 / JSF integration to new heights far beyond what Java EE 5 provides. "
+"Please see more details in the JBoss Seam reference guide bundled with the "
+"platform."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:52
+#, no-c-format
+msgid "Entity Beans (a.k.a. Java Persistence API)"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:54
+#, no-c-format
+msgid ""
+"EJB3 session beans allow you to implement data accessing business logic in "
+"transactional methods. To actually access the database, you will need EJB3 "
+"entity beans and the entity manager API. They are collectively called the "
+"Java Persistence API (JPA)."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:56
+#, no-c-format
+msgid ""
+"EJB3 Entity Beans are Plain Old Java Objects (POJOs) that map to relational "
+"database tables. For instance, the following entity bean class maps to a "
+"relational table named customer. The table has three columns: name, age, and "
+"signupdate. Each instance of the bean corresponds to a row of data in the "
+"table."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:58
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@Entity\n"
+"public class Customer {\n"
+"\n"
+" String name;\n"
+"\n"
+" public String getName () {\n"
+" return name;\n"
+" }\n"
+" \n"
+" public void setName (String name) {\n"
+" this.name = name;\n"
+" }\n"
+" \n"
+" int age;\n"
+" \n"
+" public int getAge () {\n"
+" return age;\n"
+" }\n"
+" \n"
+" public void setAge (int age) {\n"
+" this.age = age;\n"
+" }\n"
+" \n"
+" Date signupdate;\n"
+" \n"
+" public Date getSignupdate () {\n"
+" return signupdate;\n"
+" }\n"
+" \n"
+" public void setSignupdate (Date signupdate) {\n"
+" this.signupdate = signupdate;\n"
+" }\n"
+"} \n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:60
+#, no-c-format
+msgid ""
+"Besides simple data properties, the entity bean can also contain references "
+"to other entity beans with relational mapping annotations such as @OneToOne, "
+"@OneToMany, @ManyToMany etc. The relationships of those entity objects will "
+"be automatically set up in the database as foreign keys. For instance, the "
+"following example shows that each record in the Customer table has one "
+"corresponding record in the Account table, multiple corresponding records in "
+"the Order table, and each record in the Employee table has multiple "
+"corresponding records in the Customer table."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:62
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@Entity\n"
+"public class Customer {\n"
+"\n"
+" ... ...\n"
+" \n"
+" Account account;\n"
+" \n"
+" @OneToOne\n"
+" public Account getAccount () {\n"
+" return account;\n"
+" }\n"
+" \n"
+" public void setAccount (Accout account) {\n"
+" this.account = account;\n"
+" }\n"
+" \n"
+" Employee salesRep;\n"
+" \n"
+" @ManyToOne\n"
+" public Employee getSalesRep () {\n"
+" return salesRep;\n"
+" }\n"
+" \n"
+" public void setSalesRep (Employee salesRep) {\n"
+" this.salesRep = salesRep;\n"
+" }\n"
+" \n"
+" Vector <Order> orders;\n"
+" \n"
+" @OneToMany\n"
+" public Vector <Order> getOrders () {\n"
+" return orders;\n"
+" }\n"
+" \n"
+" public void setOrders (Vector <Order> orders) {\n"
+" this.orders = orders;\n"
+" }\n"
+"\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:64
+#, no-c-format
+msgid ""
+"Using the EntityManager API, you can create, update, delete, and query "
+"entity objects. The EntityManager transparently updates the underlying "
+"database tables in the process. You can obtain an EntityManager object in "
+"your EJB3 session bean via the @PersistenceContext annotation."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:66
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@PersistenceContext\n"
+"EntityManager em;\n"
+"\n"
+"Customer customer = new Customer ();\n"
+"// populate data in customer\n"
+"\n"
+"// Save the newly created customer object to DB\n"
+"em.persist (customer);\n"
+"\n"
+"// Increase age by 1 and auto save to database\n"
+"customer.setAge (customer.getAge() + 1);\n"
+"\n"
+"// delete the customer and its related objects from the DB\n"
+"em.remove (customer);\n"
+"\n"
+"// Get all customer records with age > 30 from the DB\n"
+"List <Customer> customers = em.query (\n"
+" \"select c from Customer where c.age > 30\");\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:68
+#, no-c-format
+msgid ""
+"The detailed use of the EntityManager API is beyond the scope of this book. "
+"Interested readers should refer to the JPA documentation or Hibernate "
+"EntityManager documentation."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:71
+#, no-c-format
+msgid "The persistence.xml file"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:73
+#, no-c-format
+msgid ""
+"The EntityManager API is great, but how does the server know which database "
+"it is supposed to save / update / query the entity objects? How do we "
+"configure the underlying object-relational-mapping engine and cache for "
+"better performance and trouble shooting? The persistence.xml file gives you "
+"complete flexibility to configure the EntityManager."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:75
+#, no-c-format
+msgid ""
+"The persistence.xml file is a standard configuration file in JPA. It has to "
+"be included in the META-INF directory inside the JAR file that contains the "
+"entity beans. The persistence.xml file must define a persistence-unit with a "
+"unique name in the current scoped classloader. The provider attribute "
+"specifies the underlying implementation of the JPA EntityManager. In JBoss "
+"AS, the default and only supported / recommended JPA provider is Hibernate. "
+"The jta-data-source points to the JNDI name of the database this persistence "
+"unit maps to. The java:/DefaultDS here points to the HSQL DB embedded in the "
+"JBoss AS. Please refer to <xref linkend=\"alternative_DBs\"/> on how to "
+"setup alternative databases for JBoss AS."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:77
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<persistence>\n"
+" <persistence-unit name=\"myapp\">\n"
+" <provider>org.hibernate.ejb.HibernatePersistence</provider>\n"
+" <jta-data-source>java:/DefaultDS</jta-data-source>\n"
+" <properties>\n"
+" ... ...\n"
+" </properties>\n"
+" </persistence-unit>\n"
+"</persistence> \n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:80
+#, no-c-format
+msgid "Inject EntityManager by persistence-unit name"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:81
+#, no-c-format
+msgid ""
+"Since you might have multiple instances of persistence-unit defined in the "
+"same application, you typically need to explicitly tell the "
+"@PersistenceContext annotation which unit you want to inject. For instance, "
+"@PersistenceContext(name=\"myapp\") injects the EntityManager from the "
+"persistence-unit named \"myapp\"."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:82
+#, no-c-format
+msgid ""
+"However, if you deploy your EAR application in its own scoped classloader "
+"and have only one persistence-unit defined in the whole application, you can "
+"omit the \"name\" on @PersistenceContext. See later in this chapter for EAR "
+"packaging and deployment."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:85
+#, no-c-format
+msgid ""
+"The properties element in the persistence.xml can contain any configuration "
+"properties for the underlying persistence provider. Since JBoss AS uses "
+"Hibernate as the EJB3 persistence provider, you can pass in any Hibernate "
+"options here. Please refer to the Hibernate and Hibernate EntityManager "
+"documentation for more details. Here we will just give an example to set the "
+"SQL dialect of the persistence engine to HSQL, and to create tables from the "
+"entity beans when the application starts and drop those tables when the "
+"application stops."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:87
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<persistence>\n"
+" <persistence-unit name=\"myapp\">\n"
+" <provider>org.hibernate.ejb.HibernatePersistence</provider>\n"
+" <jta-data-source>java:/DefaultDS</jta-data-source>\n"
+" <properties>\n"
+" property name=\"hibernate.dialect\" \n"
+" value=\"org.hibernate.dialect.HSQLDialect\"/>\n"
+" <property name=\"hibernate.hbm2ddl.auto\" value=\"create-drop\"/>\n"
+" </properties>\n"
+" </persistence-unit>\n"
+"</persistence> \n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:92
+#, no-c-format
+msgid "Use Alternative Databases"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:94
+#, no-c-format
+msgid ""
+"To use an alternative database other than the built-in HSQL DB to back your "
+"entity beans, you need to first define the data source for the database and "
+"register it in the JNDI. This is done via the *-ds.xml files in the deploy "
+"directory. Please see <xref linkend=\"Connectors_on_JBoss-"
+"Configuring_JDBC_DataSources\"/> for more details. Examples of *-ds.xml "
+"files for various databases are available in JBOSS_DIST/docs/examples/jca "
+"directory in the server."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:96
+#, no-c-format
+msgid ""
+"Then, in the persistence.xml, you need to change the jta-data-source "
+"attribute to point to the new data source in JNDI (e.g., java:/MysqlDS if "
+"you are using the default mysql-ds.xml to setup a MySQL external database)."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:98
+#, no-c-format
+msgid ""
+"In most cases, Hibernate tries to automatically detect the database it "
+"connects to and then automatically selects an appropriate SQL dialect for "
+"the database. However, we have found that this detection does not always "
+"work, especially for less used database servers. We recommend you to set the "
+"hibernate.dialect property explicitly in persistence.xml. Here are the "
+"Hibernate dialect for database servers officially supported on the JBoss "
+"platform."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:101
+#, no-c-format
+msgid "Oracle 9i and 10g: org.hibernate.dialect.Oracle9Dialect"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:102
+#, no-c-format
+msgid "Microsoft SQL Server 2005: org.hibernate.dialect.SQLServerDialect"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:103
+#, no-c-format
+msgid "PostgresSQL 8.1: org.hibernate.dialect.PostgreSQLDialect"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:104
+#, no-c-format
+msgid "MySQL 5.0: org.hibernate.dialect.MySQL5Dialect"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:105
+#, no-c-format
+msgid "DB2 8.0: org.hibernate.dialect.DB2Dialect"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:106
+#, no-c-format
+msgid "Sybase ASE 12.5: org.hibernate.dialect.SybaseDialect"
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:112
+#, no-c-format
+msgid "Default Hibernate options"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:114
+#, no-c-format
+msgid ""
+"Hibernate has many configuration properties. For the properties that you do "
+"not specify in the persistence.xml file, JBoss AS will provide a reasonable "
+"set of default values. The default Hibernate property values are specified "
+"in the <varname>JBOSS_DIST/server/default/deploy/ejb3.deployer/MEAT-INF/"
+"persistence.properties</varname> file. Below is the <varname>persistence."
+"properties</varname> file bundled in JBoss AS 4.2. Notice the options that "
+"are commented out. They give you an idea of available properties in your "
+"<varname>persistence.xml</varname> file."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:116
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"hibernate.transaction.manager_lookup_class=org.hibernate.transaction."
+"JBossTransactionManagerLookup\n"
+"#hibernate.connection.release_mode=after_statement\n"
+"#hibernate.transaction.flush_before_completion=false\n"
+"#hibernate.transaction.auto_close_session=false\n"
+"#hibernate.query.factory_class=org.hibernate.hql.ast."
+"ASTQueryTranslatorFactory\n"
+"#hibernate.hbm2ddl.auto=create-drop\n"
+"#hibernate.hbm2ddl.auto=create\n"
+"hibernate.cache.provider_class=org.hibernate.cache.HashtableCacheProvider\n"
+"# Clustered cache with TreeCache\n"
+"#hibernate.cache.provider_class=org.jboss.ejb3.entity.TreeCacheProviderHook\n"
+"#hibernate.treecache.mbean.object_name=jboss.cache:"
+"service=EJB3EntityTreeCache\n"
+"#hibernate.dialect=org.hibernate.dialect.HSQLDialect\n"
+"hibernate.jndi.java.naming.factory.initial=org.jnp.interfaces."
+"NamingContextFactory\n"
+"hibernate.jndi.java.naming.factory.url.pkgs=org.jboss.naming:org.jnp."
+"interfaces\n"
+"hibernate.bytecode.use_reflection_optimizer=false\n"
+"# I don't think this is honored, but EJB3Deployer uses it\n"
+"hibernate.bytecode.provider=javassist\n"
+"]]>"
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:133
+#, no-c-format
+msgid "Message Driven Beans"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:135
+#, no-c-format
+msgid ""
+"Messaging driven beans are specialized EJB3 beans that receive service "
+"requests via JMS messages instead of proxy method calls from the \"stub\". "
+"So, a crucial configuration parameter for the message driven bean is to "
+"specify which JMS message queue its listens to. When there is an incoming "
+"message in the queue, the server invokes the beans's <varname>onMessage()"
+"</varname> method, and passes in the message itself for processing. The bean "
+"class specifies the JMS queue it listens to in the @MessageDriven "
+"annotation. The queue is registered under the local JNDI java:comp/env/ name "
+"space."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:137
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"@MessageDriven(activationConfig =\n"
+"{\n"
+" @ActivationConfigProperty(propertyName=\"destinationType\",\n"
+" propertyValue=\"javax.jms.Queue\"),\n"
+" @ActivationConfigProperty(propertyName=\"destination\",\n"
+" propertyValue=\"queue/MyQueue\")\n"
+"})\n"
+"public class MyJmsBean implements MessageListener {\n"
+"\n"
+" public void onMessage (Message msg) {\n"
+" // ... do something with the msg ...\n"
+" }\n"
+"\n"
+" // ... ...\n"
+"}\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:139
+#, no-c-format
+msgid ""
+"When a message driven bean is deployed, its incoming message queue is "
+"automatically created if it does not exist already. To send a message to the "
+"bean, you can use the standard JMS API."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:141
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"try {\n"
+" InitialContext ctx = new InitialContext();\n"
+" queue = (Queue) ctx.lookup(\"queue/MyQueue\");\n"
+" QueueConnectionFactory factory =\n"
+" (QueueConnectionFactory) ctx.lookup(\"ConnectionFactory\");\n"
+" cnn = factory.createQueueConnection();\n"
+" sess = cnn.createQueueSession(false,\n"
+" QueueSession.AUTO_ACKNOWLEDGE);\n"
+"\n"
+"} catch (Exception e) {\n"
+" e.printStackTrace ();\n"
+"}\n"
+" \n"
+"TextMessage msg = sess.createTextMessage(...);\n"
+"\n"
+"sender = sess.createSender(queue);\n"
+"sender.send(msg);\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:143
+#, no-c-format
+msgid ""
+"Please refer to the JMS specification or books to learn how to program in "
+"the JMS API."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:169
+#, no-c-format
+msgid "Package and Deploy EJB3 Services"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:171
+#, no-c-format
+msgid ""
+"EJB3 bean classes are packaged in regular JAR files. The standard "
+"configuration files, such as ejb-jar.xml for session beans, and persistence."
+"xml for entity beans, are in the META-INF directory inside the JAR. You can "
+"deploy EJB3 beans as standalone services in JBoss AS or as part of an "
+"enterprise application (i.e., in an EAR archive). In this section, we "
+"discuss those two deployment options."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:174
+#, no-c-format
+msgid "Deploy the EJB3 JAR"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:176
+#, no-c-format
+msgid ""
+"When you drop JAR files into the <varname>JBOSS_DIST/server/default/deploy/</"
+"varname> directory, it will be automatically picked up and processed by the "
+"server. All the EJB3 beans defined in the JAR file will then be available to "
+"other applications deployed inside or outside of the server via JNDI names "
+"like <varname>MyBean/local</varname>, where <varname>MyBean</varname> is the "
+"implementation class name for the session bean. The deployment is done via "
+"the JBoss EJB3 deployer in JBOSS_DIST/server/default/ejb3.deployer/. The "
+"META-INF/persistence.properties file we discussed earlier to configure the "
+"default behavior of EJB3 entity manager is located in the EJB3 deployer."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:178
+#, no-c-format
+msgid ""
+"The EJB3 deployer automatically scans JARs on the classpath to look for EJB3 "
+"annotations. When it finds classes with EJB3 annotations, it would deploy "
+"them as EJB3 services. However, scanning all JARs on the classpath could be "
+"very time-consuming if you have large applications with many JARs deployed. "
+"In the JBOSS_DIST/server/default/ejb3.deployer/META-INF/jboss-service.xml "
+"file, you can tell the EJB3 deployer to ignore JARs you know do not contain "
+"EJB3 beans. The non-EJB3 JAR files shipped with the JBoss AS are already "
+"listed in the jboss.ejb3:service=JarsIgnoredForScanning MBean service:"
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:181
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+" ... ...\n"
+" <mbean code=\"org.jboss.ejb3.JarsIgnoredForScanning\" \n"
+" name=\"jboss.ejb3:service=JarsIgnoredForScanning\">\n"
+" <attribute name=\"IgnoredJars\">\n"
+" snmp-adaptor.jar,\n"
+" otherimages.jar,\n"
+" applet.jar,\n"
+" jcommon.jar,\n"
+" console-mgr-classes.jar,\n"
+" jfreechart.jar,\n"
+" juddi-service.jar,\n"
+" wsdl4j.jar,\n"
+" ... ...\n"
+" servlets-webdav.jar\n"
+" </attribute>\n"
+" </mbean>\n"
+" ... ...\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:183
+#, no-c-format
+msgid ""
+"You can add any non-EJB3 JARs from your application to this list so that the "
+"server do not have to waste time scanning them. This could significantly "
+"improve the application startup time in some cases."
+msgstr ""
+
+#. Tag: title
+#: EJB3.xml:188
+#, no-c-format
+msgid "Deploy EAR with EJB3 JAR"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:190
+#, no-c-format
+msgid ""
+"Most Java EE applications are deployed as EAR archives. An EAR archive is a "
+"JAR file that typically contains a WAR archive for the web pages, servlets, "
+"and other web-related components, one or several EJB3 JARs that provide "
+"services (e.g., data access and transaction) to the WAR components, and some "
+"other support library JARs required by the application. An EAR file also "
+"have deployment descriptors such as application.xml and jboss-app.xml. Below "
+"is the basic structure of a typical EAR application."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:192
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"myapp.ear\n"
+"|+ META-INF\n"
+" |+ applications.xml and jboss-app.xml\n"
+"|+ myapp.war\n"
+" |+ web pages and JSP /JSF pages\n"
+" |+ WEB-INF\n"
+" |+ web.xml, jboss-web.xml, faces-config.xml etc.\n"
+" |+ lib\n"
+" |+ tag library JARs\n"
+" |+ classes\n"
+" |+ servlets and other classes used by web pages\n"
+"|+ myapp.jar\n"
+" |+ EJB3 bean classes\n"
+" |+ META-INF\n"
+" |+ ejb-jar.xml and persistence.xml\n"
+"|+ lib\n"
+" |+ Library JARs for the EAR\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:194
+#, no-c-format
+msgid ""
+"Notice that in JBoss AS, unlike in many other application servers, you do "
+"not need to declare EJB references in the web.xml file in order for the "
+"components in the WAR file to access EJB3 services. You can obtain the "
+"references directly via JNDI as we discussed earlier in the chapter."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:196
+#, no-c-format
+msgid ""
+"A typical application.xml file is as follows. It declares the WAR and EJB3 "
+"JAR archives in the EAR, and defines the web content root for the "
+"application. Of course, you can have multiple EJB3 modules in the same EAR "
+"application. The application.xml file could also optionally define a shared "
+"classpath for JAR files used in this application. The JAR file location "
+"defaults to lib in JBoss AS -- but it might be different in other "
+"application servers."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:198
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<application>\n"
+" <display-name>My Application</display-name>\n"
+"\n"
+" <module>\n"
+" <web>\n"
+" <web-uri>myapp.war</web-uri>\n"
+" <context-root>/myapp</context-root>\n"
+" </web>\n"
+" </module>\n"
+"\n"
+" <module>\n"
+" <ejb>myapp.jar</ejb>\n"
+" </module>\n"
+" \n"
+" <library-directory>lib</library-directory>\n"
+"\n"
+"</application>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:200
+#, no-c-format
+msgid ""
+"The jboss-app.xml file provides JBoss-specific deployment configuration for "
+"the EAR application. For instance, it can specify the deployment order of "
+"modules in the EAR, deploy JBoss-specific application modules in the EAR, "
+"such as SARs (Service ARchive for MBeans) and HARs (Hibernate ARchive for "
+"Hibernate objects), provide security domain and JMX MBeans that can be used "
+"with this application, etc. You can lear more about the possible attributes "
+"in jboss-app.xml in its DTD: http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd."
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:202
+#, no-c-format
+msgid ""
+"A common use case for jboss-app.xml is to configure whether this EAR file "
+"should be deployed in its own scoped classloader to avoid naming conflicts "
+"with other applications. If your EAR application is deployed in its own "
+"scoped classloader and it only has one persistence-unit defined in its EJB3 "
+"JARs, you will be able to use @PersistenceContext EntotyManager em to inject "
+"EntityManager to session beans without worrying about passing the "
+"persistence unit name to the @PersistenceContext annotation. The following "
+"jboss-app.xml specifies a scoped classloader myapp:archive=myapp.ear for the "
+"EAR application."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:204
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<jboss-app>\n"
+" <loader-repository>\n"
+" myapp:archive=myapp.ear\n"
+" </loader-repository>\n"
+"</jboss-app>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:206
+#, no-c-format
+msgid ""
+"The EAR deployment is configured by the JBOSS_DIST/server/default/deploy/ear-"
+"deploy.xml file. This file contains three attributes as follows."
+msgstr ""
+
+#. Tag: programlisting
+#: EJB3.xml:208
+#, no-c-format
+msgid ""
+"<![CDATA[\n"
+"<server>\n"
+" <mbean code=\"org.jboss.deployment.EARDeployer\"\n"
+" name=\"jboss.j2ee:service=EARDeployer\">\n"
+" <!-- \n"
+" A flag indicating if ear deployments should \n"
+" have their own scoped class loader to isolate \n"
+" their classes from other deployments.\n"
+" -->\n"
+" <attribute name=\"Isolated\">false</attribute>\n"
+" \n"
+" <!-- \n"
+" A flag indicating if the ear components should \n"
+" have in VM call optimization disabled.\n"
+" -->\n"
+" <attribute name=\"CallByValue\">false</attribute>\n"
+" \n"
+" <!-- \n"
+" A flag the enables the default behavior of \n"
+" the ee5 library-directory. If true, the lib \n"
+" contents of an ear are assumed to be the default \n"
+" value for library-directory in the absence of \n"
+" an explicit library-directory. If false, there \n"
+" must be an explicit library-directory.\n"
+" -->\n"
+" <attribute name=\"EnablelibDirectoryByDefault\">true</attribute>\n"
+" </mbean>\n"
+"</server>\n"
+"]]>"
+msgstr ""
+
+#. Tag: para
+#: EJB3.xml:210
+#, no-c-format
+msgid ""
+"If you set the Isolated parameter to true, all EAR deployment will have "
+"scoped classloaders by default. There will be no need to define the "
+"classloader in jboss-app.xml. The CallByValue attribute specifies whether we "
+"should treat all EJB calls as remote calls. Remote calls have a large "
+"additional performance penalty compared with local call-by-reference calls, "
+"because objects involved in remote calls have to be serialized and de-"
+"serialized. For most of our applications, the WAR and EJB3 JARs are deployed "
+"on the same server, hence this value should be default to false and the "
+"server uses local call-by-reference calls to invoke EJB methods in the same "
+"JVM. The EnablelibDirectoryByDefault attribute specifies whether the lib "
+"directory in the EAR archive should be the default location for shared "
+"library JARs."
+msgstr ""
Added: projects/docs/trunk/Server_Configuration_Guide/es-ES/Legal_Notice.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Legal_Notice.po (rev 0)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Legal_Notice.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -0,0 +1,31 @@
+# Language es-ES translations for PACKAGE package.
+# Automatically generated, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
+"POT-Creation-Date: 2007-12-03 01:15+0000\n"
+"PO-Revision-Date: 2007-12-03 01:15+0000\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: none\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#: Legal_Notice.xml:6
+#, no-c-format
+msgid "Legal Notice"
+msgstr ""
+
+#. Tag: address
+#: Legal_Notice.xml:8
+#, no-c-format
+msgid ""
+"<street>1801 Varsity Drive</street> <city>Raleigh</city>, <state>NC</"
+"state><postcode>27606-2072</postcode><country>USA</country><phone>Phone: +1 "
+"919 754 3700</phone> <phone>Phone: 888 733 4281</phone> <fax>Fax: +1 919 754 "
+"3701</fax> <pob>PO Box 13588</pob><city>Research Triangle Park</city>, "
+"<state>NC</state><postcode>27709</postcode><country>USA</country>"
+msgstr ""
Modified: projects/docs/trunk/Server_Configuration_Guide/es-ES/Transactions.po
===================================================================
--- projects/docs/trunk/Server_Configuration_Guide/es-ES/Transactions.po 2007-12-10 06:02:22 UTC (rev 68090)
+++ projects/docs/trunk/Server_Configuration_Guide/es-ES/Transactions.po 2007-12-10 06:07:25 UTC (rev 68091)
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: JBEAP 420\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
-"POT-Creation-Date: 2007-11-06 22:32+0000\n"
+"POT-Creation-Date: 2007-12-10 06:04+0000\n"
"PO-Revision-Date: 2001-02-09 01:25+0100\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
More information about the jboss-cvs-commits
mailing list