[jboss-cvs] JBossAS SVN: r105315 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu May 27 19:13:50 EDT 2010
Author: xhuang at jboss.com
Date: 2010-05-27 19:13:49 -0400 (Thu, 27 May 2010)
New Revision: 105315
Added:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Building_Blocks.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Concepts.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Deployment.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Introduction.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JGroups.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/FAQ.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Feedback.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/General_Configuration.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/JGroups.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Performance_Tuning.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Pooling.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Remoting.po
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Revision_History.po
Log:
update
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Building_Blocks.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Building_Blocks.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Building_Blocks.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,711 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:25\n"
+"PO-Revision-Date: 2010-05-27T07:30:25\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Clustering Building Blocks"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The clustering features in JBoss Enterprise Application Platform are built on top of lower level libraries that provide much of the core functionality. <xref linkend=\"clustering-as-arch.fig\" /> shows the main pieces:"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The JBoss Enterprise Application Platform clustering architecture"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">JGroups</emphasis> is a toolkit for reliable point-to-point and point-to-multipoint communication. JGroups is used for all clustering-related communications between nodes in a JBoss Enterprise Application Platform cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">JBoss Cache</emphasis> is a highly flexible clustered transactional caching library. Many Enterprise Application Platform clustering services need to cache some state in memory while (1) ensuring for high availability purposes that a backup copy of that state is available on another node if it can't otherwise be recreated (e.g. the contents of a web session) and (2) ensuring that the data cached on each node in the cluster is consistent. JBoss Cache handles these concerns for most JBoss Enterprise Application Platform clustered services. JBoss Cache uses JGroups to handle its group communication requirements. <emphasis role=\"bold\">POJO Cache</emphasis> is an extension of the core JBoss Cache that JBoss Enterprise Application Platform uses to support fine-grained replication of clustered web session state. See <xref linkend=\"clustering-blocks-jbc\" /> for more on how JBoss Enterprise Application Platform uses JBoss Cache and POJO Cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">HAPartition</emphasis> is an adapter on top of a JGroups channel that allows multiple services to use the channel. HAPartition also supports a distributed registry of which HAPartition-based services are running on which cluster members. It provides notifications to interested listeners when the cluster membership changes or the clustered service registry changes. See <xref linkend=\"clustering-hapartition\" /> for more details on HAPartition."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The other higher level clustering services make use of JBoss Cache or HAPartition, or, in the case of HA-JNDI, both. The exception to this is JBoss Messaging's clustering features, which interact with JGroups directly."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Group Communication with JGroups"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JGroups provides the underlying group communication support for JBoss Enterprise Application Platform clusters. Services deployed on JBoss Enterprise Application Platform which need group communication with their peers will obtain a JGroups <literal>Channel</literal> and use it to communicate. The <literal>Channel</literal> handles such tasks as managing which nodes are members of the group, detecting node failures, ensuring lossless, first-in-first-out delivery of messages to all group members, and providing flow control to ensure fast message senders cannot overwhelm slow message receivers."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The characteristics of a JGroups <literal>Channel</literal> are determined by the set of <emphasis>protocols</emphasis> that compose it. Each protocol handles a single aspect of the overall group communication task; for example the <literal>UDP</literal> protocol handles the details of sending and receiving UDP datagrams. A <literal>Channel</literal> that uses the <literal>UDP</literal> protocol is capable of communicating with UDP unicast and multicast; alternatively one that uses the <literal>TCP</literal> protocol uses TCP unicast for all messages. JGroups supports a wide variety of different protocols (see <xref linkend=\"jgroups-configuration\" /> for details), but the Enterprise Application Platform ships with a default set of channel configurations that should meet most needs."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "By default, UDP multicast is used by all JGroups channels used by the Enterprise Application Platform (except for one TCP-based channel used by JBoss Messaging)."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The Channel Factory Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A significant difference in JBoss Enterprise Application Platform 5 versus previous releases is that JGroups Channels needed by clustering services (for example, a channel used by a distributed HttpSession cache) are no longer configured in detail as part of the consuming service's configuration, and are no longer directly instantiated by the consuming service. Instead, a new <literal>ChannelFactory</literal> service is used as a registry for named channel configurations and as a factory for <literal>Channel</literal> instances. A service that needs a channel requests the channel from the <literal>ChannelFactory</literal>, passing in the name of the desired configuration."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The ChannelFactory service is deployed in the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar</literal>. On startup the ChannelFactory service parses the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file, which includes various standard JGroups configurations identified by name (for example, UDP or TCP). Services needing a channel access the channel factory and ask for a channel with a particular named configuration."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If several services request a channel with the same configuration name from the ChannelFactory, they are not handed a reference to the same underlying Channel. Each receives its own Channel, but the channels will have an identical configuration. A logical question is how those channels avoid forming a group with each other if each, for example, is using the same multicast address and port. The answer is that when a consuming service connects its Channel, it passes a unique-to-that-service <literal>cluster_name</literal> argument to the <literal>Channel.connect(String cluster_name)</literal> method. The Channel uses that <literal>cluster_name</literal> as one of the factors that determine whether a particular message received over the network is intended for it."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Standard Protocol Stack Configurations"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The standard protocol stack configurations that ship with Enterprise Application Platform 5 are described below. Note that not all of these are actually used; many are included as a convenience to users who may wish to alter the default server configuration. The configurations actually used in a stock Enterprise Application Platform 5 <emphasis role=\"bold\">all</emphasis> configuration are <literal>udp</literal>, <literal>jbm-control</literal> and <literal>jbm-data</literal>, with all clustering services other than JBoss Messaging using <literal>udp</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You can add a new stack configuration by adding a new <literal>stack</literal> element to the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file. You can alter the behavior of an existing configuration by editing this file. Before doing this though, have a look at the other standard configurations the Enterprise Application Platform ships; perhaps one of those meets your needs. Also, please note that before editing a configuration you should understand what services are using that configuration; make sure the change you are making is appropriate for all affected services. If the change isn't appropriate for a particular service, perhaps its better to create a new configuration and change some services to use that new configuration."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">udp</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "UDP multicast based stack meant to be shared between different channels. Message bundling is disabled, as it can add latency to synchronous group RPCs. Services that only make asynchronous RPCs (for example, JBoss Cache configured for REPL_ASYNC) and do so in high volume may be able to improve performance by configuring their cache to use the <literal>udp-async</literal> stack below. Services that only make synchronous RPCs (for example JBoss Cache configured for REPL_SYNC or INVALIDATION_SYNC) may be able to improve performance by using the <literal>udp-sync</literal> stack below, which does not include flow control."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">udp-async</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Same as the default <literal>udp</literal> stack above, except message bundling is enabled in the transport protocol (<literal>enable_bundling=true</literal>). Useful for services that make high-volume asynchronous RPCs (e.g. high volume JBoss Cache instances configured for REPL_ASYNC) where message bundling may improve performance."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">udp-sync</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "UDP multicast based stack, without flow control and without message bundling. This can be used instead of <literal>udp</literal> if (1) synchronous calls are used and (2) the message volume (rate and size) is not that large. Don't use this configuration if you send messages at a high sustained rate, or you might run out of memory."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">tcp</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "TCP based stack, with flow control and message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (e.g. routers discard multicast)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">tcp-sync</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "TCP based stack, without flow control and without message bundling. TCP stacks are usually used when IP multicasting cannot be used in a network (e.g.routers discard multicast). This configuration should be used instead of <literal>tcp</literal> above when (1) synchronous calls are used and (2) the message volume (rate and size) is not that large. Don't use this configuration if you send messages at a high sustained rate, or you might run out of memory."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">jbm-control</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Stack optimized for the JBoss Messaging Control Channel. By default uses the same UDP transport protocol configuration as is used for the default <literal>udp</literal> stack defined above. This allows the JBoss Messaging Control Channel to use the same sockets, network buffers and thread pools as are used by the other standard JBoss Enterprise Application Platform clustered services (see <xref linkend=\"clustering-blocks-jgroups-sharedtransport\" />)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">jbm-data</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "TCP-based stack optimized for the JBoss Messaging Data Channel."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The JGroups Shared Transport"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "As the number of JGroups-based clustering services running in the Enterprise Application Platform has risen over the years, the need to share the resources (particularly sockets and threads) used by these channels became a glaring problem. A stock Enterprise Application Platform 5 <emphasis role=\"bold\">all</emphasis> configuration will connect 4 JGroups channels during startup, and a total of 7 or 8 will be connected if distributable web apps, clustered EJB3 SFSBs and a clustered JPA/Hibernate second level cache are all used. So many channels can consume a lot of resources, and can be a real configuration nightmare if the network environment requires configuration to ensure cluster isolation."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Beginning with Enterprise Application Platform 5, JGroups supports sharing of transport protocol instances between channels. A JGroups channel is composed of a stack of individual protocols, each of which is responsible for one aspect of the channel's behavior. A transport protocol is a protocol that is responsible for actually sending messages on the network and receiving them from the network. The resources that are most desirable for sharing (sockets and thread pools) are managed by the transport protocol, so sharing a transport protocol between channels efficiently accomplishes JGroups resource sharing."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To configure a transport protocol for sharing, simply add a <literal>singleton_name=\"someName\"</literal> attribute to the protocol's configuration. All channels whose transport protocol configuration uses the same <literal>singleton_name</literal> value will share their transport. All other protocols in the stack will not be shared. <xref linkend=\"clustering-blocks-jgroups-sharedtp.fig\" /> illustrates 4 services running in a VM, each with its own channel. Three of the services are sharing a transport; the fourth is using its own transport."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Services using a Shared Transport"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The protocol stack configurations used by the Enterprise Application Platform 5 ChannelFactory all have a <literal>singleton_name</literal> configured. In fact, if you add a stack to the ChannelFactory that doesn't include a <literal>singleton_name</literal>, before creating any channels for that stack, the ChannelFactory will synthetically create a <literal>singleton_name</literal> by concatenating the stack name to the string \"unnamed_\", e.g. unnamed_customStack."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Distributed Caching with JBoss Cache"
+msgstr ""
+
+#. Tag: para
+#, 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 Cache provides the underlying distributed caching support used by many of the standard clustered services in a JBoss Enterprise Application Platform cluster, including:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "replication of clustered webapp sessions"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "replication of clustered EJB3 Stateful Session beans"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "clustered caching of JPA and Hibernate entities"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "clustered Single Sign-On"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "the HA-JNDI replicated tree"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "DistributedStateService"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Users can also create their own JBoss Cache and POJO Cache instances for custom use by their applications, see <xref linkend=\"jbosscache.chapt\" /> for more on this."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The JBoss Enterprise Application Platform CacheManager Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Many of the standard clustered services in JBoss Enterprise Application Platform use JBoss Cache to maintain consistent state across the cluster. Different services (e.g. web session clustering or second level caching of JPA/Hibernate entities) use different JBoss Cache instances, with each cache configured to meet the needs of the service that uses it. In Enterprise Application Platform 4, each of these caches was independently deployed in the <literal>deploy/</literal> directory, which had a number of disadvantages:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Caches that end user applications didn't need were deployed anyway, with each creating an expensive JGroups channel. For example, even if there were no clustered EJB3 SFSBs, a cache to store them was started."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Caches are internal details of the services that use them. They shouldn't be first-class deployments."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Services would find their cache via JMX lookups. Using JMX for purposes other exposing management interfaces is just not the JBoss Enterprise Application Platform 5 way."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In JBoss Enterprise Application Platform 5, the scattered cache deployments have been replaced with a new <emphasis role=\"bold\">CacheManager</emphasis> service, deployed via the <literal>JBOSS_HOME/server/all/deploy/cluster/jboss-cache-manager.sar</literal>. The CacheManager is a factory and registry for JBoss Cache instances. It is configured with a set of named JBoss Cache configurations. Services that need a cache ask the cache manager for the cache by name; the cache manager creates the cache (if not already created) and returns it. The cache manager keeps a reference to each cache it has created, so all services that request the same cache configuration name will share the same cache. When a service is done with the cache, it releases it to the cache manager. The cache manager keeps track of how many services are using each cache, and will stop and destroy the cache when all services have released it."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Standard Cache Configurations"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following standard JBoss Cache configurations ship with JBoss Enterprise Application Platform 5. You can add others to suit your needs, or edit these configurations to adjust cache behavior. Additions or changes are done by editing the <literal>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</literal> file (see <xref linkend=\"jbosscache-custom-deployment-cachemgr\" /> for details). Note however that these configurations are specifically optimized for their intended use, and except as specifically noted in the documentation chapters for each service in this guide, it is not advisable to change them."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">standard-session-cache</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Standard cache used for web sessions."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">field-granularity-session-cache</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Standard cache used for FIELD granularity web sessions."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">sfsb-cache</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Standard cache used for EJB3 SFSB caching."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">ha-partition</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Used by web tier Clustered Single Sign-On, HA-JNDI, Distributed State."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mvcc-entity</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for JPA/Hibernate entity/collection caching that uses JBC's MVCC locking (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">optimistic-entity</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for JPA/Hibernate entity/collection caching that uses JBC's optimistic locking (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">pessimistic-entity</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for JPA/Hibernate entity/collection caching that uses JBC's pessimistic locking (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mvcc-entity-repeatable</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Same as \"mvcc-entity\" but uses JBC's REPEATABLE_READ isolation level instead of READ_COMMITTED (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">pessimistic-entity-repeatable</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Same as \"pessimistic-entity\" but uses JBC's REPEATABLE_READ isolation level instead of READ_COMMITTED (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">local-query</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for JPA/Hibernate query result caching. Does not replicate query results. DO NOT store the timestamp data Hibernate uses to verify validity of query results in this cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">replicated-query</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for JPA/Hibernate query result caching. Replicates query results. DO NOT store the timestamp data Hibernate uses to verify validity of query result in this cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">timestamps-cache</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for the timestamp data cached as part of JPA/Hibernate query result caching. A replicated timestamp cache is required if query result caching is used, even if the query results themselves use a non-replicating cache like <literal>local-query</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mvcc-shared</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for a cache that's shared for JPA/Hibernate entity, collection, query result and timestamp caching. Not an advised configuration, since it requires cache mode REPL_SYNC, which is the least efficient mode. Also requires a full state transfer at startup, which can be expensive. Maintained for backwards compatibility reasons, as a shared cache was the only option in JBoss 4. Uses JBC's MVCC locking."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">optimistic-shared</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for a cache that's shared for JPA/Hibernate entity, collection, query result and timestamp caching. Not an advised configuration, since it requires cache mode REPL_SYNC, which is the least efficient mode. Also requires a full state transfer at startup, which can be expensive. Maintained for backwards compatibility reasons, as a shared cache was the only option in JBoss 4. Uses JBC's optimistic locking."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">pessimistic-shared</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A configuration appropriate for a cache that's shared for JPA/Hibernate entity, collection, query result and timestamp caching. Not an advised configuration, since it requires cache mode REPL_SYNC, which is the least efficient mode. Also requires a full state transfer at startup, which can be expensive. Maintained for backwards compatibility reasons, as a shared cache was the only option in JBoss 4. Uses JBC's pessimistic locking."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mvcc-shared-repeatable</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Same as \"mvcc-shared\" but uses JBC's REPEATABLE_READ isolation level instead of READ_COMMITTED (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">pessimistic-shared-repeatable</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Same as \"pessimistic-shared\" but uses JBC's REPEATABLE_READ isolation level instead of READ_COMMITTED. (see notes below)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For more on JBoss Cache's locking schemes, see <xref linkend=\"jbosscache-configuration-concurrency\" />)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For JPA/Hibernate second level caching, REPEATABLE_READ is only useful if the application evicts/clears entities from the EntityManager/Hibernate Session and then expects to repeatably re-read them in the same transaction. Otherwise, the Session's internal cache provides a repeatable-read semantic."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Cache Configuration Aliases"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The CacheManager also supports aliasing of caches; i.e. allowing caches registered under one name to be looked up under a different name. Aliasing is useful for sharing caches between services whose configuration may specify different cache configuration names. It's also useful for supporting legacy EJB3 application configurations ported over from Enterprise Application Platform 4."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Aliases can be configured by editing the \"CacheManager\" bean in the <literal>jboss-cache-manager-jboss-beans.xml</literal> file. The following redacted configuration shows the standard aliases in Enterprise Application Platform 5:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"CacheManager\" class=\"org.jboss.ha.cachemanager.CacheManager\">\n"
+"\n"
+" . . .\n"
+"\n"
+" <!-- Aliases for cache names. Allows caches to be shared across \n"
+" services that may expect different cache configuration names. -->\n"
+" <property name=\"configAliases\">\n"
+" <map keyClass=\"java.lang.String\" valueClass=\"java.lang.String\">\n"
+" <!-- Use the HAPartition cache for ClusteredSSO caching -->\n"
+" <entry>\n"
+" <key>clustered-sso</key>\n"
+" <value>ha-partition</value>\n"
+" </entry>\n"
+" <!-- Handle the legacy name for the EJB3 SFSB cache -->\n"
+" <entry>\n"
+" <key>jboss.cache:service=EJB3SFSBClusteredCache</key>\n"
+" <value>sfsb-cache</value>\n"
+" </entry>\n"
+" <!-- Handle the legacy name for the EJB3 Entity cache -->\n"
+" <entry>\n"
+" <key>jboss.cache:service=EJB3EntityTreeCache</key>\n"
+" <value>mvcc-shared</value>\n"
+" </entry>\n"
+" </map>\n"
+" </property>\n"
+" \n"
+" . . .\n"
+" \n"
+"</bean>"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The HAPartition Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "HAPartition is a general purpose service used for a variety of tasks in Enterprise Application Platform clustering. At its core, it is an abstraction built on top of a JGroups <literal>Channel</literal> that provides support for making/receiving RPC invocations on/from one or more cluster members. HAPartition allows services that use it to share a single <literal>Channel</literal> and multiplex RPC invocations over it, eliminating the configuration complexity and runtime overhead of having each service create its own <literal>Channel</literal>. 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 en!
tity cache management, farming, HA-JNDI and HA singletons. Custom services can also make use of HAPartition."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following snippet shows the <literal>HAPartition</literal> service definition packaged with the standard JBoss Enterprise Application Platform distribution. This configuration can be found in the <literal>server/all/deploy/cluster/hapartition-jboss-beans.xml</literal> file."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"HAPartitionCacheHandler\" class=\"org.jboss.ha.framework.server.HAPartitionCacheHandlerImpl\">\n"
+" <property name=\"cacheManager\"><inject bean=\"CacheManager\"/></property>\n"
+" <property name=\"cacheConfigName\">ha-partition</property>\n"
+"</bean>\n"
+"<bean name=\"HAPartition\" class=\"org.jboss.ha.framework.server.ClusterPartition\">\n"
+" <depends>jboss:service=Naming</depends>\n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"jboss:service=HAPartition,partition=${jboss.partition.name:DefaultPartition}\", exposedInterface=org.jboss.ha.framework.server.ClusterPartitionMBean.class, registerDirectly=true)</annotation>\n"
+" \n"
+" <!-- ClusterPartition requires a Cache for state management -->\n"
+" \n"
+" <property name=\"cacheHandler\"><inject bean=\"HAPartitionCacheHandler\"/></property>\n"
+" \n"
+" <!-- Name of the partition being built -->\n"
+" \n"
+" <property name=\"partitionName\">${jboss.partition.name:DefaultPartition}</property>\n"
+" \n"
+" <!-- The address used to determine the node name -->\n"
+" \n"
+" <property name=\"nodeAddress\">${jboss.bind.address}</property>\n"
+" \n"
+" <!-- Max time (in ms) to wait for state transfer to complete. Increase for large states -->\n"
+" \n"
+" <property name=\"stateTransferTimeout\">30000</property>\n"
+" \n"
+" <!-- Max time (in ms) to wait for RPC calls to complete. -->\n"
+" \n"
+" <property name=\"methodCallTimeout\">60000</property>\n"
+" \n"
+" <!-- Optionally provide a thread source to allow async connect of our channel -->\n"
+" \n"
+" <property name=\"threadPool\"><inject bean=\"jboss.system:service=ThreadPool\"/></property>\n"
+" <property name=\"distributedStateImpl\">\n"
+" <bean name=\"DistributedState\" class=\"org.jboss.ha.framework.server.DistributedStateImpl\"> \n"
+" \n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"jboss:service=DistributedState,partitionName=${jboss.partition.name:DefaultPartition}\", exposedInterface=org.jboss.ha.framework.server.DistributedStateImplMBean.class, registerDirectly=true)</annotation>\n"
+" \n"
+" <property name=\"cacheHandler\"><inject bean=\"HAPartitionCacheHandler\"/></property> \n"
+" </bean>\n"
+" </property>\n"
+"</bean>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Much of the above is generic; below we'll touch on the key points relevant to end users. There are two beans defined above, the <literal>HAPartitionCacheHandler</literal> and the <literal>HAPartition</literal> itself."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>HAPartition</literal> bean itself exposes the following configuration properties:"
+msgstr ""
+
+#. Tag: para
+#, 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 server startup."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">nodeAddress</emphasis> is unused and can be ignored."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">stateTransferTimeout</emphasis> specifies the timeout (in milliseconds) for initial application state transfer. State transfer refers to the process of obtaining a serialized copy of initial application state from other already-running cluster members at service startup. Its default value is <literal>30000</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">methodCallTimeout</emphasis> specifies the timeout (in milliseconds) for obtaining responses to group RPCs from the other cluster members. Its default value is <literal>60000</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>HAPartitionCacheHandler</literal> is a small utility service that helps the HAPartition integrate with JBoss Cache (see <xref linkend=\"clustering-blocks-jbc-cachemanager\" />). HAPartition exposes a child service called DistributedState (see <xref linkend=\"clustering-hapartition-distributedstate\" />) that uses JBoss Cache; the <literal>HAPartitionCacheHandler</literal> helps ensure consistent configuration between the JGroups <literal>Channel</literal> used by Distributed State's cache and the one used directly by HAPartition."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">cacheConfigName</emphasis> the name of the JBoss Cache configuration to use for the HAPartition-related cache. Indirectly, this also specifies the name of the JGroups protocol stack configuration HAPartition should use. See <xref linkend=\"jbosscache-configuration-jgroups\" /> for more on how the JGroups protocol stack is configured."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In order for nodes to form a cluster, they must have the exact same <literal>partitionName</literal> and the <literal>HAPartitionCacheHandler</literal>'s <literal>cacheConfigName</literal> must specify an identical JBoss Cache configuration. Changes in either element on some but not all nodes would prevent proper clustering behavior."
+msgstr ""
+
+#. Tag: para
+#, 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=HAPartition,partition=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
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "DistributedReplicantManager Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>DistributedReplicantManager</literal> (DRM) service is a component of the HAPartition service made available to HAPartition users via the <literal>HAPartition.getDistributedReplicantManager()</literal> method. Generally speaking, JBoss Enterprise Application Platform users will not directly make use of the DRM; we discuss it here as an aid to those who want a deeper understanding of how Enterprise Application Platform clustering internals work."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The DRM is a distributed registry that allows HAPartition users to register objects under a given key, making available to callersthe set of objects registered under that key by the various members of t he cluster. The DRM also provides a notification mechanism so interested listeners can be notified when the contents of the registry changes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There are two main usages for the DRM in JBoss Enterprise Application Platform:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Clustered Smart Proxies</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Here the keys are the names of the various services that need a clustered smart proxy (see <xref linkend=\"clustering-concepts-arch-proxy\" />, e.g. the name of a clustered EJB. The value object each node stores in the DRM is known as a \"target\". It's something a smart proxy's transport layer can use to contact the node (e.g. an RMI stub, an HTTP URL or a JBoss Remoting <literal>InvokerLocator</literal>). The factory that builds clustered smart proxies accesses the DRM to get the set of \"targets\" that should be injected into the proxy to allow it to communicate with all the nodes in a cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">HASingleton</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Here the keys are the names of the various services that need to function as High Availablity Singletons (see the HASingleton chapter). The value object each node stores in the DRM is simply a String that acts as a token to indicate that the node has the service deployed, and thus is a candidate to become the \"master\" node for the HA singleton service."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In both cases, the key under which objects are registered identifies a particular clustered service. It is useful to understand that every node in a cluster doesn't have to register an object under every key. Only services that are deployed on a particular node will register something under that service's key, and services don't have to be deployed homogeneously across the cluster. The DRM is thus useful as a mechanism for understanding a service's \"topology\" around the cluster — which nodes have the service deployed."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "DistributedState Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>DistributedState</literal> service is a legacy component of the HAPartition service made available to HAPartition users via the <literal>HAPartition.getDistributedState()</literal> method. This service provides coordinated management of arbitary application state around the cluster. 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
+#, no-c-format
+msgid "In JBoss Enterprise Application Platform 5 the <literal>DistributedState</literal> service actually delegates to an underlying JBoss Cache instance."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Custom Use of HAPartition"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Custom services can also use make use of HAPartition to handle interactions with the cluster. Generally the easiest way to do this is to extend the <literal>org.jboss.ha.framework.server.HAServiceImpl</literal> base class, or the <literal>org.jboss.ha.jxm.HAServiceMBeanSupport</literal> class if JMX registration and notification support are desired."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Concepts.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Concepts.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Concepts.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,179 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:25\n"
+"PO-Revision-Date: 2010-05-27T07:30:25\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Clustering Concepts"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the next section, we discuss basic concepts behind JBoss' clustering services. It is helpful that you understand these concepts before reading the rest of the <emphasis>Clustering Guide</emphasis>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Cluster Definition"
+msgstr ""
+
+#. Tag: para
+#, 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 Enterprise Application Platform cluster (also known as a “partition”), a node is an JBoss Enterprise Application Platform instance. Communication between the nodes is handled by the JGroups group communication library, with a JGroups <literal>Channel</literal> 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 Enterprise Application Platform instances on the same network is enough for them to form a cluster – each Enterprise Application Platform starts a <literal>Channel</literal> (actually, several) with the same default configuration, so they dynamically discover each other and form a cluster. Nodes can be d!
ynamically added to or removed from clusters at any time, simply by starting or stopping a <literal>Channel</literal> with a configuration and name that matches the other cluster members."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On the same Enterprise Application Platform instance, different services can create their own <literal>Channel</literal>. In a standard startup of the Enterprise Application Platform 5 <emphasis>all</emphasis> configuration, two different services create a total of four different channels – JBoss Messaging creates two and a core general purpose clustering service known as HAPartition creates two more. If you deploy clustered web applications, clustered EJB3 SFSBs or a clustered JPA/Hibernate entity cache, additional channels will be created. The channels the Enterprise Application Platform connects can be divided into three broad categories: a general purpose channel used by the HAPartition service, channels created by JBoss Cache for special purpose caching and cluster wide state replication, and two channels used by JBoss Messaging."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "So, if you go to two Enterprise Application Platform 5.0.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 multiple channels, and hence multiple two node clusters."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On the same network, you may have different sets of servers whose services wish to cluster. <xref linkend=\"clustering-Partition.fig\" /> shows an example network of JBoss server instances divided into three sets, with the third set only having one node. This sort of topology can be set up simply by configuring the Enterprise Application Platform 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 channel configurations and names match while they differ from any other channels on the same network. The Enterprise Application Platform tries to make this is easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the <literal>-g</literal> (partition name) and <literal>-u</literal> (multicast address) startup switches. For each set of servers, different values should be chosen. The sections on “JGroups Configurat!
ion” and “Isolating JGroups Channels” cover in detail how to configure the Enterprise Application Platform such that desired peers find each other and unwanted peers do not."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Clusters and server nodes"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Service Architectures"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The clustering topography defined by the JGroups configuration on each node is of great importance to system administrators. But for most application developers, the greater concern is probably the cluster architecture from a client application's point of view. Two basic clustering architectures are used with JBoss Enterprise Application Platform: 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
+#, no-c-format
+msgid "Client-side interceptor architecture"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Most remote services provided by the JBoss Enterprise Application Platform, including JNDI, EJB, JMS, RMI and JBoss Remoting, require the client to obtain (for example, to look up and download) a remote proxy object. The proxy object is generated by the server and it implements the business interface of the service. The client then makes local method calls against the proxy object. The proxy automatically routes the call across the network where it is invoked against service objects managed in the server. The proxy object figures out how to find the appropriate server node, marshal call parameters, unmarshal call results, and return the result to the caller client. In a clustered environment, the server-generated proxy object includes an interceptor that understands how to route calls to multiple nodes in the cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The proxy's clustering logic maintains up-to-date knowledge about the cluster. For instance, it knows 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 proxy with the latest changes in the cluster. For instance, if a node drops out of the cluster, each proxy is updated with the new topology the next time it connects to any active node in the cluster. All the manipulations done by the proxy's clustering logic are transparent to the client application. The client-side interceptor clustering architecture is illustrated in <xref linkend=\"clustering-InterceptorArch.fig\" />."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "The client-side interceptor (proxy) architecture for clustering"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "External Load Balancer Architecture"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The HTTP-based JBoss services do not require the client to download anything. The client (for example, a web browser) sends in requests and receives responses directly over the wire using 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 how to contact the load balancer; it has no knowledge of the JBoss Enterprise Application Platform 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 Enterprise Application Platform 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 clu!
ster 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
+#, no-c-format
+msgid "The external load balancer architecture for clustering"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "Load Balancing Policies"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine to which server node a new request should be sent. In this section, let's go over the load balancing policies available in JBoss Enterprise Application Platform."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In JBoss Enterprise Application Platform 5, 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. Each policy has two implementation classes, one meant for use by legacy services like EJB2 that use the legacy detached invoker architecture, and the other meant for services like EJB3 that use AOP-based invocations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Round-Robin: 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. Implemented by <literal>org.jboss.ha.framework.interfaces.RoundRobin</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RoundRobin</literal> (EJB3)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Random-Robin: for each call the target node is randomly selected from the list. Implemented by <literal>org.jboss.ha.framework.interfaces.RandomRobin</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RandomRobin </literal> (EJB3)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "First Available: 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 proxy elects its own target node independently of the other proxies, so if a particular client downloads two proxies for the same target service (for example, an EJB), each proxy 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. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailable</literal> (EJB3)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "First Available Identical All Proxies: has the same behavior as the \"First Available\" policy but the elected target node is shared by all proxies in the same client-side VM that are associated with the same target service. So if a particular client downloads two proxies for the same target service (e.g. an EJB), each proxy will use the same target. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies</literal> (EJB3)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Each of the above is an implementation of the <classname>org.jboss.ha.framework.interfaces.LoadBalancePolicy</classname> 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
+#, no-c-format
+msgid "External load balancer architecture"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "New in JBoss Enterprise Application Platform 5 are a set of \"TransactionSticky\" load balance policies. These extend the standard policies above to add behavior such that all invocations that occur within the scope of a transaction are routed to the same node (if that node still exists). These are based on the legacy detached invoker architecture, so they are not available for AOP-based services like EJB3."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Transaction-Sticky Round-Robin: Transaction-sticky variant of Round-Robin. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyRoundRobin</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Transaction-Sticky Random-Robin: Transaction-sticky variant of Random-Robin. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyRandomRobin</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Transaction-Sticky First Available: Transaction-sticky variant of First Available. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailable</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Transaction-Sticky First Available Identical All Proxies: Transaction-sticky variant of First Available Identical All Proxies. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailableIdenticalAllProxies</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Each of the above is an implementation of a simple interface; users are free to write their own implementations if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Deployment.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Deployment.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Deployment.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,435 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:25\n"
+"PO-Revision-Date: 2010-05-27T07:30:25\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Clustered Deployment Options"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Clustered Singleton Services"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A clustered singleton service (also known as a 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."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Topology before the Master Node fails"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "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
+#, no-c-format
+msgid "Topology after the Master Node fails"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "HASingleton Deployment Options"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JBoss Enterprise Application Platform 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
+#, no-c-format
+msgid "HASingletonDeployer service"
+msgstr ""
+
+#. Tag: para
+#, 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 <literal>deploy</literal> nor <literal>farm</literal> directories, so its contents are not automatically deployed when an Enterprise Application Platform instance starts. Instead, deploying the contents of this directory is the responsibility of a special service, the <literal>HASingletonDeployer</literal> bean (which itself is deployed via the deploy/deploy-hasingleton-jboss-beans.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 (ty!
pically at server shutdown), is to undeploy the contents of <literal>deploy-hasingleton</literal>."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "Using deploy-hasingleton is very simple, but it does have two drawbacks:"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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 the complexity of your service's deployment, and the extent of startup activity in which it engages, this could take a while, during which time the service is not being provided."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "POJO deployments using HASingletonController"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your service is a POJO (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
+#, no-c-format
+msgid "First, we have a POJO that we want to make an HA singleton. The only thing special about it is it needs to expose a public 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
+#, no-c-format
+msgid "\n"
+"public interface HASingletonExampleMBean\n"
+"{\n"
+" boolean isMasterNode();\n"
+"}\n"
+"\n"
+"\n"
+"public class HASingletonExample implements HASingletonExampleMBean\n"
+"{\n"
+" private boolean isMasterNode = false; \n"
+"\n"
+" public boolean isMasterNode()\n"
+" {\n"
+" return isMasterNode; \n"
+" }\n"
+"\n"
+" public void startSingleton()\n"
+" { \n"
+" isMasterNode = true;\n"
+" }\n"
+"\n"
+" public void stopSingleton()\n"
+" {\n"
+" isMasterNode = false; \n"
+" }\n"
+"}\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "We used <literal>startSingleton</literal> and <literal>stopSingleton</literal> in the above example, but you could name the methods anything."
+msgstr ""
+
+#. Tag: para
+#, 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-beans.xml</literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<deployment xmlns=\"urn:jboss:bean-deployer:2.0\">\n"
+" <!-- This bean is an example of a clustered singleton -->\n"
+" <bean name=\"HASingletonExample\" class=\"org.jboss.ha.examples.HASingletonExample\">\n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"jboss:service=HASingletonExample\", \n"
+" exposedInterface=org.jboss.ha.examples.HASingletonExampleMBean.class)</annotation>\n"
+" </bean>\n"
+"\n"
+" <bean name=\"ExampleHASingletonController\" class=\"org.jboss.ha.singleton.HASingletonController\">\n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"jboss:service=ExampleHASingletonController\", \n"
+" exposedInterface=org.jboss.ha.singleton.HASingletonControllerMBean.class, \n"
+" registerDirectly=true)</annotation>\n"
+" <property name=\"HAPartition\"><inject bean=\"HAPartition\"/></property>\n"
+" <property name=\"target\"><inject bean=\"HASingletonExample\"/></property>\n"
+" <property name=\"targetStartMethod\">startSingleton</property>\n"
+" <property name=\"targetStopMethod\">stopSingleton</property>\n"
+" </bean>\n"
+"</deployment>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Voila! A clustered singleton service."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The primary advantage of this approach over deploy-ha-singleton. is 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
+#, no-c-format
+msgid "Although not demonstrated in the example above, the <literal>HASingletonController</literal> can support an optional argument for either or both of the target start and stop methods. These are specified using the <literal>targetStartMethodArgument</literal> and <literal>TargetStopMethodArgument</literal> properties, respectively. Currently, only string values are supported."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "HASingleton deployments using a Barrier"
+msgstr ""
+
+#. Tag: para
+#, 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 service:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<depends>HASingletonDeployerBarrierController</depends>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The way it works is that a BarrierController is deployed along with the HASingletonDeployer 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 bean 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 also destroyed."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, 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: title
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "Determining the master node"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "For each member of the cluster, the HAPartition service 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
+#, 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
+#, 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
+#, 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 uses the <literal>HAPartition</literal>'s <literal>HASingletonElectionPolicy</literal> to determine if they are the master, as explained in the <xref linkend=\"ha-singleton-election-policy\" />."
+msgstr ""
+
+#. Tag: para
+#, 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 ""
+
+#. Tag: title
+#, no-c-format
+msgid "HA singleton election policy"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>HASingletonElectionPolicy</literal> object is responsible for electing a master node from a list of available nodes, on behalf of an HA singleton, following a change in cluster topology."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"public interface HASingletonElectionPolicy\n"
+"{\n"
+" ClusterNode elect(List<ClusterNode> nodes);\n"
+"}\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform ships with two election policies:"
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<literal>HASingletonElectionPolicySimple</literal>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This policy selects a master node based relative age. The desired age is configured via the <literal>position</literal> property, which corresponds to the index in the list of available nodes. <literal>position = 0</literal>, the default, refers to the oldest node; <literal>position = 1</literal>, refers to the 2nd oldest; etc. <literal>position</literal> can also be negative to indicate youngness; imagine the list of available nodes as a circular linked list. <literal>position = -1</literal>, refers to the youngest node; <literal>position = -2</literal>, refers to the 2nd youngest node; etc."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean class=\"org.jboss.ha.singleton.HASingletonElectionPolicySimple\">\n"
+" <property name=\"position\">-1</property>\n"
+"</bean>\n"
+""
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<literal>PreferredMasterElectionPolicy</literal>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This policy extends <literal>HASingletonElectionPolicySimple</literal>, allowing the configuration of a preferred node. The <literal>preferredMaster</literal> property, specified as <emphasis>host:port</emphasis> or <emphasis>address:port</emphasis>, identifies a specific node that should become master, if available. If the preferred node is not available, the election policy will behave as described above."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean class=\"org.jboss.ha.singleton.PreferredMasterElectionPolicy\">\n"
+" <property name=\"preferredMaster\">server1:12345</property>\n"
+"</bean>\n"
+""
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Farming Deployment"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The easiest way to deploy an application into the cluster is to use the farming service. Using the farming service, you can deploy an application (e.g. EAR, WAR, or SAR; either an archive file or in exploded form) to the <literal>all/farm/</literal> directory of any cluster member and the application will be automatically duplicate across all nodes in the same cluster. If a 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 a running clustered server node's <literal>farm/</literal> directory, the application will be undeployed locally and then removed from all other clustered server nodes' <literal>farm/</literal> directories (triggering undeployment)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Farming is enabled by default in the <literal>all</literal> configuration in JBoss Enterprise Application Platform and thus requires no manual setup. The required <filename>farm-deployment-jboss-beans.xml</filename> and <filename>timestamps-jboss-beans.xml</filename> configuration files are located in the <literal>deploy/cluster</literal> directory. If you want to enable farming in a custom configuration, simply copy these files to the corresponding JBoss deploy directory <literal>$JBOSS_HOME/server/your_own_config/deploy/cluster</literal>. Make sure that your custom configuration has clustering enabled."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "While there is little need to customize the farming service, it can be customized via the <literal>FarmProfileRepositoryClusteringHandler</literal> bean, whose properties and default values are listed below:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"FarmProfileRepositoryClusteringHandler\"\n"
+" class=\"org.jboss.profileservice.cluster.repository.\n"
+" DefaultRepositoryClusteringHandler\">\n"
+" \n"
+" <property name=\"partition\"><inject bean=\"HAPartition\"/></property>\n"
+" <property name=\"profileDomain\">default</property>\n"
+" <property name=\"profileServer\">default</property>\n"
+" <property name=\"profileName\">farm</property>\n"
+" <property name=\"immutable\">false</property>\n"
+" <property name=\"lockTimeout\">60000</property><!-- 1 minute -->\n"
+" <property name=\"methodCallTimeout\">60000</property><!-- 1 minute -->\n"
+" <property name=\"synchronizationPolicy\"><inject bean=\"FarmProfileSynchronizationPolicy\"/></property>\n"
+"</bean>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">partition</emphasis> is a required attribute to inject the HAPartition service that the farm service uses for intra-cluster communication."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">profile[Domain|Server|Name]</emphasis> are all used to identify the profile for which this handler is intended."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">immutable</emphasis> indicates whether or not this handler allows a node to push content changes to the cluster. A value of <literal>true</literal> is equivalent to setting <literal>synchronizationPolicy</literal> to <literal>org.jboss.system.server.profileservice.repository.clustered.sync.</literal> <literal>ImmutableSynchronizationPolicy</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">lockTimeout</emphasis> defines the number of milliseconds to wait for cluster-wide lock acquisition."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">methodCallTimeout</emphasis> defines the number of milliseconds to wait for invocations on remote cluster nodes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">synchronizationPolicy</emphasis> decides how to handle content additions, reincarnations, updates, or removals from nodes attempting to join the cluster or from cluster merges. The policy is consulted on the \"authoritative\" node, i.e. the master node for the service on the cluster. <emphasis>Reincarnation</emphasis> refers to the phenomenon where a newly started node may contain an application in its <literal>farm/</literal> directory that was previously removed by the farming service but might still exist on the starting node if it was not running when the removal took place. The default synchronization policy is defined as follows:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"FarmProfileSynchronizationPolicy\"\n"
+" class=\"org.jboss.profileservice.cluster.repository.\n"
+" DefaultSynchronizationPolicy\">\n"
+" <property name=\"allowJoinAdditions\"><null/></property>\n"
+" <property name=\"allowJoinReincarnations\"><null/></property>\n"
+" <property name=\"allowJoinUpdates\"><null/></property>\n"
+" <property name=\"allowJoinRemovals\"><null/></property>\n"
+" <property name=\"allowMergeAdditions\"><null/></property>\n"
+" <property name=\"allowMergeReincarnations\"><null/></property>\n"
+" <property name=\"allowMergeUpdates\"><null/></property>\n"
+" <property name=\"allowMergeRemovals\"><null/></property>\n"
+" <property name=\"developerMode\">false</property>\n"
+" <property name=\"removalTrackingTime\">2592000000</property><!-- 30 days -->\n"
+" <property name=\"timestampService\"><inject bean=\"TimestampDiscrepancyService\"/></property>\n"
+"</bean>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">allow[Join|Merge][Additions|Reincarnations|Updates|Removals]</emphasis> define fixed responses to requests to allow additions, reincarnations, updates, or removals from joined or merged nodes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">developerMode</emphasis> enables a lenient synchronization policy that allows all changes. Enabling developer mode is equivalent to setting each of the above properties to <literal>true</literal> and is intended for development environments."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">removalTrackingTime</emphasis> defines the number of milliseconds for which this policy should remembered removed items, for use in detecting reincarnations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">timestampService</emphasis> estimates and tracks discrepancies in system clocks for current and past members of the cluster. Default implementation is defined in <filename>timestamps-jboss-beans.xml</filename>."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Introduction.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Introduction.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_Introduction.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,487 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:26\n"
+"PO-Revision-Date: 2010-05-27T07:30:26\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Introduction and Quick Start"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Clustering allows you 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 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
+#, no-c-format
+msgid "The JBoss Enterprise Application Platform comes with clustering support out of the box, as part of the <literal>all</literal> configuration. The <literal>all</literal> configuration includes support for the following:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A scalable, fault-tolerant JNDI implementation (HA-JNDI)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Web tier clustering, including:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "High availability for web session state via state replication."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Ability to integrate with hardware and software load balancers, including special integration with mod_jk and other JK-based software load balancers."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Single Sign-on support across a cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "EJB session bean clustering, for both stateful and stateless beans, and for both EJB3 and EJB2."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A distributed cache for JPA/Hibernate entities."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A framework for keeping local EJB2 entity caches consistent across a cluster by invalidating cache entries across the cluster when a bean is changed on any node."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Distributed JMS queues and topics via JBoss Messaging."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Deploying a service or application on multiple nodes in the cluster but having it active on only one (but at least one) node is called a <emphasis>HA Singleton</emphasis>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Keeping deployed content in sync on all nodes in the cluster via the <literal>Farm</literal> service."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In this <emphasis>Clustering Guide</emphasis> we aim to provide you with an in depth understanding of how to use JBoss Enterprise Application Platform's clustering features. In this first part of the guide, the goal is to provide some basic \"Quick Start\" steps to encourage you to start experimenting with JBoss Enterprise Application Platform Clustering, and then to provide some background information that will allow you to understand how JBoss Enterprise Application Platform Clustering works. The next part of the guide then explains in detail how to use these features to cluster your JEE services. Finally, we provide some more details about advanced configuration of JGroups and JBoss Cache, the core technologies that underlie JBoss Enterprise Application Platform Clustering."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Quick Start Guide"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The goal of this section is to give you the minimum information needed to let you get started experimenting with JBoss Enterprise Application Platform Clustering. Most of the areas touched on in this section are covered in much greater detail later in this guide."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Initial Preparation"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Preparing a set of servers to act as a JBoss Enterprise Application Platform cluster involves a few simple steps:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Install JBoss Enterprise Application Platform on all your servers.</emphasis> In its simplest form, this is just a matter of unzipping the JBoss download onto the filesystem on each server."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you want to run multiple JBoss Enterprise Application Platform instances on a single server, you can either install the full JBoss distribution onto multiple locations on your filesystem, or you can simply make copies of the <literal>all</literal> configuration. For example, assuming the root of the JBoss distribution was unzipped to <literal>/var/jboss</literal>, you would:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/server\n"
+"$ cp -r all node1\n"
+"$ cp -r all node2"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">For each node, determine the address to bind sockets to.</emphasis> When you start JBoss, whether clustered or not, you need to tell JBoss on what address its sockets should listen for traffic. (The default is <literal>localhost</literal> which is secure but isn't very useful, particularly in a cluster.) So, you need to decide what those addresses will be."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Ensure multicast is working.</emphasis> By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster communications. Make sure each server's networking configuration supports multicast and that multicast support is enabled for any switches or routers between your servers. If you are planning to run more than one node on a server, make sure the server's routing table includes a multicast route. See the JGroups documentation at <ulink url=\"http://www.jgroups.org\">http://www.jgroups.org</ulink> for more on this general area, including information on how to use JGroups' diagnostic tools to confirm that multicast is working."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform clustering does not require the use of UDP multicast; the Enterprise Application Platform can also be reconfigured to use TCP unicast for intra-cluster communication."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Determine a unique integer \"ServerPeerID\" for each node.</emphasis> This is needed for JBoss Messaging clustering, and can be skipped if you will not be running JBoss Messaging (i.e. you will remove JBM from your server configuration's <literal>deploy</literal> directory). JBM requires that each node in a cluster has a unique integer id, known as a \"ServerPeerID\", that should remain consistent across server restarts. A simple 1, 2, 3, ..., x naming scheme is fine. We'll cover how to use these integer ids in the next section."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Beyond the above required steps, the following two optional steps are recommended to help ensure that your cluster is properly isolated from other JBoss Enterprise Application Platform clusters that may be running on your network:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Pick a unique name for your cluster.</emphasis> The default name for a JBoss Enterprise Application Platform cluster is \"DefaultPartition\". Come up with a different name for each cluster in your environment, e.g. \"QAPartition\" or \"BobsDevPartition\". The use of \"Partition\" is not required; it's just a semi-convention. As a small aid to performance try to keep the name short, as it gets included in every message sent around the cluster. We'll cover how to use the name you pick in the next section."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Pick a unique multicast address for your cluster.</emphasis> By default JBoss Enterprise Application Platform uses UDP multicast for most intra-cluster communication. Pick a different multicast address for each cluster you run. Generally a good multicast address is of the form <literal>239.255.x.y</literal>. See <ulink url=\"http://www.29west.com/docs/THPM/multicast-address-assignment.html\"> http://www.29west.com/docs/THPM/multicast-address-assignment.html </ulink> for a good discussion on multicast address assignment. We'll cover how to use the address you pick in the next section."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "See <xref linkend=\"clustering-jgroups-isolation\" /> for more on isolating clusters."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Launching a JBoss Enterprise Application Platform Cluster"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The simplest way to start a JBoss server cluster is to start several JBoss instances on the same local network, using the <literal>-c all</literal> command line option for each instance. Those server instances will detect each other and automatically form a cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Let's look at a few different scenarios for doing this. In each scenario we'll be creating a two node cluster, where the ServerPeerID for the first node is <literal>1</literal> and for the second node is <literal>2</literal> . We've decided to call our cluster \"DocsPartition\" and to use <literal>239.255.100.100</literal> as our multicast address. These scenarios are meant to be illustrative; the use of a two node cluster shouldn't be taken to mean that is the best size for a cluster; it's just that's the simplest way to do the examples."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Scenario 1: Nodes on Separate Machines</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This is the most common production scenario. Assume the machines are named \"node1\" and \"node2\", while node1 has an IP address of <literal>192.168.0.101</literal> and node2 has an address of <literal>192.168.0.102</literal>. Assume the \"ServerPeerID\" for node1 is <literal>1</literal> and for node2 it's <literal>2</literal>. Assume on each machine JBoss is installed in <literal>/var/jboss</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On node1, to launch JBoss:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On node2, it's the same except for a different <literal>-b</literal> value and ServerPeerID:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c all -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>-c</literal> switch says to use the <literal>all</literal> config, which includes clustering support. The <literal>-g</literal> switch sets the cluster name. The <literal>-u</literal> switch sets the multicast address that will be used for intra-cluster communication. The <literal>-b</literal> switch sets the address on which sockets will be bound. The <literal>-D</literal> switch sets system property <literal>jboss.messaging.ServerPeerID</literal>, from which JBoss Messaging gets its unique id."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Scenario 2: Two Nodes on a Single, Multihomed, Server</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Running multiple nodes on the same machine is a common scenario in a development environment, and is also used in production in combination with Scenario 1. (Running <emphasis>all</emphasis> the nodes in a production cluster on a single machine is generally not recommended, since the machine itself becomes a single point of failure.) In this version of the scenario, the machine is multihomed, i.e. has more than one IP address. This allows the binding of each JBoss instance to a different address, preventing port conflicts when the nodes open sockets."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Assume the single machine has the <literal>192.168.0.101</literal> and <literal>192.168.0.102</literal> addresses assigned, and that the two JBoss instances use the same addresses and ServerPeerIDs as in Scenario 1. The difference from Scenario 1 is we need to be sure each Enterprise Application Platform instance has its own work area. So, instead of using the <literal>all</literal> config, we are going to use the <literal>node1</literal> and <literal>node2</literal> configs we copied from <literal>all</literal> earlier in the previous section."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To launch the first instance, open a console window and:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For the second instance, it's the same except for different <emphasis>-b</emphasis> and <emphasis>-c</emphasis> values and a different ServerPeerID:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Scenario 3: Two Nodes on a Single, Non-Multihomed, Server</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This is similar to Scenario 2, but here the machine only has one IP address available. Two processes can't bind sockets to the same address and port, so we'll have to tell JBoss to use different ports for the two instances. This can be done by configuring the ServiceBindingManager service by setting the <literal>jboss.service.binding.set</literal> system property."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \\\n"
+" -Djboss.service.binding.set=ports-default"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For the second instance:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"$ cd /var/jboss/bin\n"
+"$ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \\\n"
+" -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \\\n"
+" -Djboss.service.binding.set=ports-01"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This tells the ServiceBindingManager on the first node to use the standard set of ports (e.g. JNDI on 1099). The second node uses the \"ports-01\" binding set, which by default for each port has an offset of 100 from the standard port number (e.g. JNDI on 1199). See the <literal>conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml</literal> file for the full ServiceBindingManager configuration."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Note that this setup is not advised for production use, due to the increased management complexity that comes with using different ports. But it is a fairly common scenario in development environments where developers want to use clustering but cannot multihome their workstations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Including <literal>-Djboss.service.binding.set=ports-default</literal> on the command line for node1 isn't technically necessary, since <literal>ports-default</literal> is the default value. But using a consistent set of command line arguments across all servers is helpful to people less familiar with all the details."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "That's it; that's all it takes to get a cluster of JBoss Enterprise Application Platform servers up and running."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Web Application Clustering Quick Start"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform supports clustered web sessions, where a backup copy of each user's <literal>HttpSession</literal> state is stored on one or more nodes in the cluster. In case the primary node handling the session fails or is shut down, any other node in the cluster can handle subsequent requests for the session by accessing the backup copy. Web tier clustering is discussed in detail in <xref linkend=\"clustering-http\" />."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There are two aspects to setting up web tier clustering:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Configuring an External Load Balancer</emphasis>. Web applications require an external load balancer to balance HTTP requests across the cluster of JBoss Enterprise Application Platform instances (see <xref linkend=\"clustering-concepts-arch-balancer\" /> for more on why that is). JBoss Enterprise Application Platform itself doesn't act as an HTTP load balancer. So, you will need to set up a hardware or software load balancer. There are many possible load balancer choices, so how to configure one is really beyond the scope of a Quick Start. But see <xref linkend=\"clustering-http-modjk\" /> for details on how to set up the popular mod_jk software load balancer."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Configuring Your Web Application for Clustering</emphasis>. This aspect involves telling JBoss you want clustering behavior for a particular web app, and it couldn't be simpler. Just add an empty <literal>distributable</literal> element to your application's <literal>web.xml</literal> file:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<?xml version=\"1.0\"?> \n"
+"<web-app xmlns=\"http://java.sun.com/xml/ns/javaee\"\n"
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \n"
+" xsi:schemaLocation=\"http://java.sun.com/xml/ns/javaee \n"
+" http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd\" \n"
+" version=\"2.5\">\n"
+" \n"
+" <distributable/>\n"
+" \n"
+"</web-app>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Simply doing that is enough to get the default JBoss Enterprise Application Platform web session clustering behavior, which is appropriate for most applications. See <xref linkend=\"clustering-http-state\" /> for more advanced configuration options."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "EJB Session Bean Clustering Quick Start"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform supports clustered EJB session beans, whereby requests for a bean are balanced across the cluster. For stateful beans a backup copy of bean state is maintained on one or more cluster nodes, providing high availability in case the node handling a particular session fails or is shut down. Clustering of both EJB2 and EJB3 beans is supported."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For EJB3 session beans, simply add the <literal>org.jboss.ejb3.annotation.Clustered</literal> annotation to the bean class for your stateful or stateless bean:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"@javax.ejb.Stateless\n"
+"@org.jboss.ejb3.annotation.Clustered\n"
+"public class MyBean implements MySessionInt {\n"
+" \n"
+" public void test() {\n"
+" // Do something cool\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For EJB2 session beans, or for EJB3 beans where you prefer XML configuration over annotations, simply add a <literal>clustered</literal> element to the bean's section in the JBoss-specific deployment descriptor, <literal>jboss.xml</literal>:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<jboss> \n"
+" <enterprise-beans> \n"
+" <session> \n"
+" <ejb-name>example.StatelessSession</ejb-name> \n"
+" <jndi-name>example.StatelessSession</jndi-name> \n"
+" <clustered>true</clustered>\n"
+" </session>\n"
+" </enterprise-beans>\n"
+"</jboss> "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "See <xref linkend=\"clustering-session\" /> for more advanced configuration options."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Entity Clustering Quick Start"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "One of the big improvements in the clustering area in JBoss Enterprise Application Platform 5 is the use of the new Hibernate/JBoss Cache integration for second level entity caching that was introduced in Hibernate 3.3. In the JPA/Hibernate context, a second level cache refers to a cache whose contents are retained beyond the scope of a transaction. A second level cache <emphasis>may</emphasis> improve performance by reducing the number of database reads. You should always load test your application with second level caching enabled and disabled to see whether it has a beneficial impact on your particular application."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you use more than one JBoss Enterprise Application Platform instance to run your JPA/Hibernate application and you use second level caching, you must use a cluster-aware cache. Otherwise a cache on server A will still hold out-of-date data after activity on server B updates some entities."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform provides a cluster-aware second level cache based on JBoss Cache. To tell JBoss Enterprise Application Platform's standard Hibernate-based JPA provider to enable second level caching with JBoss Cache, configure your <literal>persistence.xml</literal> as follows:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+"<persistence xmlns=\"http://java.sun.com/xml/ns/persistence\"\n"
+" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n"
+" xsi:schemaLocation=\"http://java.sun.com/xml/ns/persistence\n"
+" http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd\"\n"
+" version=\"1.0\"> \n"
+" <persistence-unit name=\"somename\" transaction-type=\"JTA\">\n"
+" <jta-data-source>java:/SomeDS</jta-data-source>\n"
+" <properties>\n"
+" <property name=\"hibernate.cache.use_second_level_cache\" value=\"true\"/>\n"
+" <property name=\"hibernate.cache.region.factory_class\" \n"
+" value=\"org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory\"/>\n"
+" <property name=\"hibernate.cache.region.jbc2.cachefactory\" value=\"java:CacheManager\"/>\n"
+" <!-- Other configuration options ... -->\n"
+" </properties>\n"
+" </persistence-unit>\n"
+"</persistence>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "That tells Hibernate to use the JBoss Cache-based second level cache, but it doesn't tell it what entities to cache. That can be done by adding the <literal>org.hibernate.annotations.Cache</literal> annotation to your entity class:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"package org.example.entities;\n"
+" \n"
+"import java.io.Serializable;\n"
+"import javax.persistence.Entity;\n"
+"import org.hibernate.annotations.Cache;\n"
+"import org.hibernate.annotations.CacheConcurrencyStrategy;\n"
+" \n"
+"@Entity\n"
+"@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)\n"
+"public class Account implements Serializable {\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "See <xref linkend=\"clustering-entity\" /> for more advanced configuration options and details on how to configure the same thing for a non-JPA Hibernate application."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Clustering can add significant overhead to a JPA/Hibernate second level cache, so don't assume that just because second level caching adds a benefit to a non-clustered application that it will be beneficial to a clustered application. Even if clustered second level caching is beneficial overall, caching of more frequently modified entity types may be beneficial in a non-clustered scenario but not in a clustered one. <emphasis>Always</emphasis> load test your application."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,1130 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:26\n"
+"PO-Revision-Date: 2010-05-27T07:30:26\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "JBoss Cache Configuration and Deployment"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Cache provides the underlying distributed caching support used by many of the standard clustered services in a JBoss Enterprise Application Platform cluster. You can also deploy JBoss Cache in your own application to handle custom caching requirements. In this chapter we provide some background on the main configuration options available with JBoss Cache, with an emphasis on how those options relate to the JBoss Cache usage by the standard clustered services the Enterprise Application Platform provides. We then discuss the different options available for deploying a custom cache in the Enterprise Application Platform."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Users considering deploying JBoss Cache for direct use by their own application are strongly encouraged to read the JBoss Cache documentation available at <ulink url=\"http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/\">http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/</ulink>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "See also <xref linkend=\"clustering-blocks-jbc\" /> for information on how the standard JBoss Enterprise Application Platform clustered services use JBoss Cache."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Key JBoss Cache Configuration Options"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform ships with a reasonable set of default JBoss Cache configurations that are suitable for the standard clustered service use cases (e.g. web session replication or JPA/Hibernate caching). Most applications that involve the standard clustered services just work out of the box with the default configurations. You only need to tweak them when you are deploying an application that has special network or performance requirements. In this section we provide a brief overview of some of the key configuration choices. This is by no means a complete discussion; for full details users interested in moving beyond the default configurations are encouraged to read the JBoss Cache documentation available at <ulink url=\"http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/\">http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/</ulink>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Most JBoss Cache configuration examples in this section use the JBoss Microcontainer schema for building up an <literal>org.jboss.cache.config.Configuration</literal> object graph from XML. JBoss Cache has its own custom XML schema, but the standard JBoss Enterprise Application Platform CacheManager service uses the JBoss Microcontainer schema to be consistent with most other internal Enterprise Application Platform services."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Before getting into the key configuration options, let's have a look at the most likely place that a user would encounter them."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Editing the CacheManager Configuration"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "As discussed in <xref linkend=\"clustering-blocks-jbc-cachemanager\" />, the standard JBoss Enterprise Application Platform clustered services use the CacheManager service as a factory for JBoss Cache instances. So, cache configuration changes are likely to involve edits to the CacheManager service."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Users can also use the CacheManager as a factory for custom caches used by directly by their own applications; see <xref linkend=\"jbosscache-custom-deployment-cachemgr\" />."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The CacheManager is configured via the <literal>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</literal> file. The element most likely to be edited is the \"CacheConfigurationRegistry\" bean, which maintains a registry of all the named JBC configurations the CacheManager knows about. Most edits to this file would involve adding a new JBoss Cache configuration or changing a property of an existing one."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following is a redacted version of the \"CacheConfigurationRegistry\" bean configuration:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"CacheConfigurationRegistry\" \n"
+" class=\"org.jboss.ha.cachemanager.DependencyInjectedConfigurationRegistry\">\n"
+" \n"
+" <!-- If users wish to add configs using a more familiar JBC config format\n"
+" they can add them to a cache-configs.xml file specified by this property.\n"
+" However, use of the microcontainer format used below is recommended.\n"
+" <property name=\"configResource\">META-INF/jboss-cache-configs.xml</property> \n"
+" -->\n"
+" \n"
+" <!-- The configurations. A Map<String name, Configuration config> -->\n"
+" <property name=\"newConfigurations\">\n"
+" <map keyClass=\"java.lang.String\" valueClass=\"org.jboss.cache.config.Configuration\">\n"
+" \n"
+" <!-- The standard configurations follow. You can add your own and/or edit these. --> \n"
+" \n"
+" <!-- Standard cache used for web sessions -->\n"
+" <entry><key>standard-session-cache</key>\n"
+" <value> \n"
+" <bean name=\"StandardSessionCacheConfig\" class=\"org.jboss.cache.config.Configuration\">\n"
+" \n"
+" <!-- Provides batching functionality for caches that don't want to \n"
+" interact with regular JTA Transactions -->\n"
+" <property name=\"transactionManagerLookupClass\">\n"
+" org.jboss.cache.transaction.BatchModeTransactionManagerLookup\n"
+" </property>\n"
+" \n"
+" <!-- Name of cluster. Needs to be the same for all members -->\n"
+" <property name=\"clusterName\">${jboss.partition.name:DefaultPartition}-SessionCache</property>\n"
+" <!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)\n"
+" because we are using asynchronous replication. -->\n"
+" <property name=\"multiplexerStack\">${jboss.default.jgroups.stack:udp}</property>\n"
+" <property name=\"fetchInMemoryState\">true</property>\n"
+" \n"
+" <property name=\"nodeLockingScheme\">PESSIMISTIC</property>\n"
+" <property name=\"isolationLevel\">REPEATABLE_READ</property>\n"
+" <property name=\"cacheMode\">REPL_ASYNC</property>\n"
+" \n"
+" .... more details of the standard-session-cache configuration\n"
+" </bean> \n"
+" </value>\n"
+" </entry>\n"
+" \n"
+" <!-- Appropriate for web sessions with FIELD granularity -->\n"
+" <entry><key>field-granularity-session-cache</key>\n"
+" <value> \n"
+" \n"
+" <bean name=\"FieldSessionCacheConfig\" class=\"org.jboss.cache.config.Configuration\"> \n"
+" .... details of the field-granularity-standard-session-cache configuration\n"
+" </bean> \n"
+"\n"
+" </value>\n"
+"\n"
+" </entry>\n"
+"\n"
+" ... entry elements for the other configurations\n"
+"\n"
+" </map>\n"
+" </property>\n"
+"</bean>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The actual JBoss Cache configurations are specified using the JBoss Microcontainer's schema rather than one of the standard JBoss Cache configuration formats. When JBoss Cache parses one of its standard configuration formats, it creates a Java Bean of type <literal>org.jboss.cache.config.Configuration</literal> with a tree of child Java Beans for some of the more complex sub-configurations (i.e. cache loading, eviction, buddy replication). Rather than delegating this task of XML parsing/Java Bean creation to JBC, we let the Enterprise Application Platform's microcontainer do it directly. This has the advantage of making the microcontainer aware of the configuration beans, which in later Enterprise Application Platform 5.x releases will be helpful in allowing external management tools to manage the JBC configurations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configuration format should be fairly self-explanatory if you look at the standard configurations the Enterprise Application Platform ships; they include all the major elements. The types and properties of the various java beans that make up a JBoss Cache configuration can be seen in the JBoss Cache javadocs. Here is a fairly complete example:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"StandardSFSBCacheConfig\" class=\"org.jboss.cache.config.Configuration\">\n"
+"\n"
+" <!-- No transaction manager lookup -->\n"
+" \n"
+" <!-- Name of cluster. Needs to be the same for all members -->\n"
+" <property name=\"clusterName\">${jboss.partition.name:DefaultPartition}-SFSBCache</property>\n"
+" <!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)\n"
+" because we are using asynchronous replication. -->\n"
+" <property name=\"multiplexerStack\">${jboss.default.jgroups.stack:udp}</property>\n"
+" <property name=\"fetchInMemoryState\">true</property>\n"
+" \n"
+" <property name=\"nodeLockingScheme\">PESSIMISTIC</property>\n"
+" <property name=\"isolationLevel\">REPEATABLE_READ</property>\n"
+" <property name=\"cacheMode\">REPL_ASYNC</property>\n"
+" \n"
+" <property name=\"useLockStriping\">false</property>\n"
+"\n"
+" <!-- Number of milliseconds to wait until all responses for a\n"
+" synchronous call have been received. Make this longer \n"
+" than lockAcquisitionTimeout.-->\n"
+" <property name=\"syncReplTimeout\">17500</property>\n"
+" <!-- Max number of milliseconds to wait for a lock acquisition -->\n"
+" <property name=\"lockAcquisitionTimeout\">15000</property>\n"
+" <!-- The max amount of time (in milliseconds) we wait until the\n"
+" state (ie. the contents of the cache) are retrieved from\n"
+" existing members at startup. -->\n"
+" <property name=\"stateRetrievalTimeout\">60000</property>\n"
+"\n"
+" <!--\n"
+" SFSBs use region-based marshalling to provide for partial state\n"
+" transfer during deployment/undeployment.\n"
+" -->\n"
+" <property name=\"useRegionBasedMarshalling\">false</property>\n"
+" <!-- Must match the value of \"useRegionBasedMarshalling\" -->\n"
+" <property name=\"inactiveOnStartup\">false</property>\n"
+" \n"
+" <!-- Disable asynchronous RPC marshalling/sending -->\n"
+" <property name=\"serializationExecutorPoolSize\">0</property> \n"
+" <!-- We have no asynchronous notification listeners -->\n"
+" <property name=\"listenerAsyncPoolSize\">0</property>\n"
+" \n"
+" <property name=\"exposeManagementStatistics\">true</property>\n"
+"\n"
+" <property name=\"buddyReplicationConfig\">\n"
+" <bean class=\"org.jboss.cache.config.BuddyReplicationConfig\">\n"
+" \n"
+" <!-- Just set to true to turn on buddy replication -->\n"
+" <property name=\"enabled\">false</property>\n"
+" \n"
+" <!-- A way to specify a preferred replication group. We try\n"
+" and pick a buddy who shares the same pool name (falling \n"
+" back to other buddies if not available). -->\n"
+" <property name=\"buddyPoolName\">default</property>\n"
+" \n"
+" <property name=\"buddyCommunicationTimeout\">17500</property>\n"
+" \n"
+" <!-- Do not change these -->\n"
+" <property name=\"autoDataGravitation\">false</property>\n"
+" <property name=\"dataGravitationRemoveOnFind\">true</property>\n"
+" <property name=\"dataGravitationSearchBackupTrees\">true</property>\n"
+" \n"
+" <property name=\"buddyLocatorConfig\">\n"
+" <bean class=\"org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig\">\n"
+" <!-- The number of backup nodes we maintain -->\n"
+" <property name=\"numBuddies\">1</property>\n"
+" <!-- Means that each node will *try* to select a buddy on \n"
+" a different physical host. If not able to do so \n"
+" though, it will fall back to colocated nodes. -->\n"
+" <property name=\"ignoreColocatedBuddies\">true</property>\n"
+" </bean>\n"
+" </property>\n"
+" </bean>\n"
+" </property>\n"
+" <property name=\"cacheLoaderConfig\">\n"
+" <bean class=\"org.jboss.cache.config.CacheLoaderConfig\">\n"
+" <!-- Do not change these -->\n"
+" <property name=\"passivation\">true</property>\n"
+" <property name=\"shared\">false</property>\n"
+" \n"
+" <property name=\"individualCacheLoaderConfigs\">\n"
+" <list>\n"
+" <bean class=\"org.jboss.cache.loader.FileCacheLoaderConfig\">\n"
+" <!-- Where passivated sessions are stored -->\n"
+" <property name=\"location\">${jboss.server.data.dir}${/}sfsb</property>\n"
+" <!-- Do not change these -->\n"
+" <property name=\"async\">false</property>\n"
+" <property name=\"fetchPersistentState\">true</property>\n"
+" <property name=\"purgeOnStartup\">true</property>\n"
+" <property name=\"ignoreModifications\">false</property>\n"
+" <property name=\"checkCharacterPortability\">false</property>\n"
+" </bean>\n"
+" </list>\n"
+" </property>\n"
+" </bean>\n"
+" </property>\n"
+" \n"
+" <!-- EJBs use JBoss Cache eviction -->\n"
+" <property name=\"evictionConfig\">\n"
+" <bean class=\"org.jboss.cache.config.EvictionConfig\">\n"
+" <property name=\"wakeupInterval\">5000</property>\n"
+" <!-- Overall default -->\n"
+" <property name=\"defaultEvictionRegionConfig\">\n"
+" <bean class=\"org.jboss.cache.config.EvictionRegionConfig\">\n"
+" <property name=\"regionName\">/</property>\n"
+" <property name=\"evictionAlgorithmConfig\">\n"
+" <bean class=\"org.jboss.cache.eviction.NullEvictionAlgorithmConfig\"/>\n"
+" </property>\n"
+" </bean>\n"
+" </property>\n"
+" <!-- EJB3 integration code will programatically create\n"
+" other regions as beans are deployed -->\n"
+" </bean>\n"
+" </property>\n"
+"</bean>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Basically, the XML specifies the creation of an <literal>org.jboss.cache.config.Configuration</literal> java bean and the setting of a number of properties on that bean. Most of the properties are of simple types, but some, such as <literal>buddyReplicationConfig</literal> and <literal>cacheLoaderConfig</literal> take various types java beans as their values."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Next we'll look at some of the key configuration options."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Cache Mode"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Cache's <literal>cacheMode</literal> configuration attribute combines into a single property two related aspects:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Handling of Cluster Updates</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This controls how a cache instance on one node should notify the rest of the cluster when it makes changes in its local state. There are three options:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Synchronous</emphasis> means the cache instance sends a message to its peers notifying them of the change(s) and before returning waits for them to acknowledge that they have applied the same changes. If the changes are made as part of a JTA transaction, this is done as part of a 2 phase-commit process during transaction commit. Any locks are held until this acknowledgment is received. Waiting for acknowledgement from all nodes adds delays, but it ensures consistency around the cluster. Synchronous mode is needed when all the nodes in the cluster may access the cached data resulting in a high need for consistency."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Asynchronous</emphasis> means the cache instance sends a message to its peers notifying them of the change(s) and then immediately returns, without any acknowledgement that they have applied the same changes. It <emphasis>does not</emphasis> mean sending the message is handled by some other thread besides the one that changed the cache content; the thread that makes the change still spends some time dealing with sending messages to the cluster, just not as much as with synchronous communication. Asynchronous mode is most useful for cases like session replication, where the cache doing the sending expects to be the only one that accesses the data and the cluster messages are used to provide backup copies in case of failure of the sending node. Asynchronous messaging adds a small risk that a later user request that fails over to another node may see out-of-date state, but for many session-type applications this risk is acceptable given the major!
performance benefits asynchronous mode has over synchronous mode."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Local</emphasis> means the cache instance doesn't send a message at all. A JGroups channel isn't even used by the cache. JBoss Cache has many useful features besides its clustering capabilities and is a very useful caching library even when not used in a cluster. Also, even in a cluster, some cached data does not need to be kept consistent around the cluster, in which case Local mode will improve performance. Caching of JPA/Hibernate query result sets is an example of this; Hibernate's second level caching logic uses a separate mechanism to invalidate stale query result sets from the second level cache, so JBoss Cache doesn't need to send messages around the cluster for a query result set cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Replication vs. Invalidation</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This aspect deals with the content of messages sent around the cluster when a cache changes its local state, i.e. what should the other caches in the cluster do to reflect the change:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Replication</emphasis> means the other nodes should update their state to reflect the new state on the sending node. This means the sending node needs to include the changed state, increasing the cost of the message. Replication is necessary if the other nodes have no other way to obtain the state."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Invalidation</emphasis> means the other nodes should remove the changed state from their local state. Invalidation reduces the cost of the cluster update messages, since only the cache key of the changed state needs to be transmitted, not the state itself. However, it is only an option if the removed state can be retrieved from another source. It is an excellent option for a clustered JPA/Hibernate entity cache, since the cached state can be re-read from the database."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "These two aspects combine to form 5 valid values for the <literal>cacheMode</literal> configuration attribute:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">LOCAL</emphasis> means no cluster messages are needed."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">REPL_SYNC</emphasis> means synchronous replication messages are sent."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">REPL_ASYNC</emphasis> means asynchronous replication messages are sent."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">INVALIDATION_SYNC</emphasis> means synchronous invalidation messages are sent."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">INVALIDATION_ASYNC</emphasis> means asynchronous invalidation messages are sent."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Transaction Handling"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Cache integrates with JTA transaction managers to allow transactional access to the cache. When JBoss Cache detects the presence of a transaction, any locks are held for the life of the transaction, changes made to the cache will be reverted if the transaction rolls back, and any cluster-wide messages sent to inform other nodes of changes are deferred and sent in a batch as part of transaction commit (reducing chattiness)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Integration with a transaction manager is accomplished by setting the <literal>transactionManagerLookupClass</literal> configuration attribute; this specifies the fully qualified class name of a class JBoss Cache can use to find the local transaction manager. Inside JBoss Enterprise Application Platform, this attribute would have one of two values:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">org.jboss.cache.transaction.JBossTransactionManagerLookup</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This finds the standard transaction manager running in the application server. Use this for any custom caches you deploy where you want caching to participate in any JTA transactions."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">org.jboss.cache.transaction.BatchModeTransactionManagerLookup</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This is used in the cache configurations used for web session and EJB SFSB caching. It specifies a simple mock <literal>TransactionManager</literal> that ships with JBoss Cache called the <literal>BatchModeTransactionManager</literal>. This transaction manager is not a true JTA transaction manager and should not be used for anything other than JBoss Cache. Its usage in JBoss Enterprise Application Platform is to get most of the benefits of JBoss Cache's transactional behavior for the session replication use cases, but without getting tangled up with end user transactions that may run during a request."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For caches used for JPA/Hibernate caching, the <literal>transactionManagerLookupClass</literal> should not be configured. Hibernate internally configures the cache to use the same transaction manager it is using for database access."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Concurrent Access"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Cache is a thread safe caching API, and uses its own efficient mechanisms of controlling concurrent access. Concurrency is configured via the <literal>nodeLockingScheme</literal> and <literal>isolationLevel</literal> configuration attributes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There are three choices for <literal>nodeLockingScheme</literal>:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">MVCC</emphasis> or multi-versioned concurrency control, is a locking scheme commonly used by modern database implementations to control fast, safe concurrent access to shared data. JBoss Cache 3.x uses an innovative implementation of MVCC as the default locking scheme. MVCC is designed to provide the following features for concurrent access:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Readers that don't block writers"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Writers that fail fast"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "It achieves this by using data versioning and copying for concurrent writers. The theory is that readers continue reading shared state, while writers copy the shared state, increment a version id, and write that shared state back after verifying that the version is still valid (i.e., another concurrent writer has not changed this state first)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "MVCC is the recommended choice for JPA/Hibernate entity caching."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">PESSIMISTIC</emphasis> locking involves threads/transactions acquiring either exclusive or non-exclusive locks on nodes before reading or writing. Which is acquired depends on the <literal>isolationLevel</literal> (see below) but in most cases a non-exclusive lock is acquired for a read and an exclusive lock is acquired for a write. Pessimistic locking requires considerably more overhead than MVCC and allows lesser concurrency, since reader threads must block until a write has completed and released its exclusive lock (potentially a long time if the write is part of a transaction). A write will also be delayed due to ongoing reads."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Generally MVCC is a better choice than PESSIMISTIC, which is deprecated as of JBoss Cache 3.0. But, for the session caching usage in JBoss Enterprise Application Platform 5.0.0, PESSIMISTIC is still the default. This is largely because for the session use case there are generally not concurrent threads accessing the same cache location, so the benefits of MVCC are not as great."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">OPTIMISTIC</emphasis> locking seeks to improve upon the concurrency available with PESSIMISTIC by creating a \"workspace\" for each request/transaction that accesses the cache. Data accessed by the request/transaction (even reads) is <emphasis>copied</emphasis> into the workspace, which is adds overhead. All data is versioned; on completion of non-transactional requests or commits of transactions the version of data in the workspace is compared to the main cache, and an exception is raised if there are are inconsistencies. Otherwise changes to the workspace are applied to the main cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "OPTIMISTIC locking is deprecated but is still provided to support backward compatibility. Users are encouraged to use MVCC instead, which provides the same benefits at lower cost."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>isolationLevel</literal> attribute has two possible values <emphasis role=\"bold\">READ_COMMITTED</emphasis> and <emphasis role=\"bold\">REPEATABLE_READ</emphasis> which correspond in semantic to database-style isolation levels. Previous versions of JBoss Cache supported all 5 database isolation levels, and if an unsupported isolation level is configured, it is either upgraded or downgraded to the closest supported level."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "REPEATABLE_READ is the default isolation level, to maintain compatibility with previous versions of JBoss Cache. READ_COMMITTED, while providing a slightly weaker isolation, has a significant performance benefit over REPEATABLE_READ."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "JGroups Integration"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Each JBoss Cache instance internally uses a JGroups <literal>Channel</literal> to handle group communications. Inside JBoss Enterprise Application Platform, we strongly recommend that you use the Enterprise Application Platform's JGroups Channel Factory service as the source for your cache's <literal>Channel</literal>. In this section we discuss how to configure your cache to get it's channel from the Channel Factory; if you wish to configure the channel in some other way see the JBoss Cache documentation."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Caches obtained from the CacheManager Service</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This is the simplest approach. The CacheManager service already has a reference to the Channel Factory service, so the only configuration task is to configure the name of the JGroups protocol stack configuration to use."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you are configuring your cache via the CacheManager service's <literal>jboss-cache-manager-jboss-beans.xml</literal> file (see <xref linkend=\"jbosscache-custom-deployment-cachemgr\" />), add the following to your cache configuration, where the value is the name of the protocol stack configuration.:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<property name=\"multiplexerStack\">udp</property>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Caches Deployed via a <literal>-jboss-beans.xml</literal> File</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you are deploying a cache via a JBoss Microcontainer <literal>-jboss-beans.xml</literal> file (see <xref linkend=\"jbosscache-custom-deployment-beans.xml\" />), you need inject a reference to the Channel Factory service as well as specifying the protocol stack configuration:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<property name=\"runtimeConfig\">\n"
+" <bean class=\"org.jboss.cache.config.RuntimeConfig\">\n"
+" <property name=\"muxChannelFactory\"><inject bean=\"JChannelFactory\"/></property>\n"
+" </bean>\n"
+"</property>\n"
+"<property name=\"multiplexerStack\">udp</property>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Caches Deployed via a <literal>-service.xml</literal> File</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you are deploying a cache MBean via <literal>-service.xml</literal> file (see <xref linkend=\"jbosscache-custom-deployment-service.xml\" />), <literal>CacheJmxWrapper</literal> is the class of your MBean; that class exposes a <literal>MuxChannelFactory</literal> MBean attribute. You dependency inject the Channel Factory service into this attribute, and set the protocol stack name via the <literal>MultiplexerStack</literal> attribute:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<attribute name=\"MuxChannelFactory\"><inject bean=\"JChannelFactory\"/></attribute>\n"
+"<attribute name=\"MultiplexerStack\">udp</attribute>"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Eviction"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Eviction allows the cache to control memory by removing data (typically the least frequently used data). If you wish to configure eviction for a custom cache, see the JBoss Cache documentation for all of the available options. For details on configuring it for JPA/Hibernate caching, see the Eviction chapter in the \"Using JBoss Cache as a Hibernate Second Level Cache\" guide at <ulink url=\"http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf\">http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf</ulink>. For web session caches, eviction should not be configured; the distributable session manager handles eviction itself. For EJB 3 SFSB caches, stick with the eviction configuration in the Enterprise Application Platform's standard <literal>sfsb-cache</literal> configuration (see <xref linkend=\"clustering-blocks-jbc-cachemanager\" />). The EJB container will configure eviction itself using the values included in each bean's !
configuration."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Cache Loaders"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Cache loading allows JBoss Cache to store data in a persistent store in addition to what it keeps in memory. This data can either be an overflow, where the data in the persistent store is not reflected in memory. Or it can be a superset of what is in memory, where everything in memory is also reflected in the persistent store, along with items that have been evicted from memory. Which of these two modes is used depends on the setting of the <literal>passivation</literal> flag in the JBoss Cache cache loader configuration section. A <literal>true</literal> value means the persistent store acts as an overflow area written to when data is evicted from the in-memory cache."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you wish to configure cache loading for a custom cache, see the JBoss Cache documentation for all of the available options. Do not configure cache loading for a JPA/Hibernate cache, as the database itself serves as a persistent store; adding a cache loader is just redundant."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The caches used for web session and EJB3 SFSB caching use passivation. Next we'll discuss the cache loader configuration for those caches in some detail."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "CacheLoader Configuration for Web Session and SFSB Caches"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "HttpSession and SFSB passivation rely on JBoss Cache's Cache Loader passivation for storing and retrieving the passivated sessions. Therefore the cache instance used by your webapp's clustered session manager or your bean's EJB container must be configured to enable Cache Loader passivaton."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In most cases you don't need to do anything to alter the cache loader configurations for the standard web session and SFSB caches; the standard JBoss Enterprise Application Platform configurations should suit your needs. The following is a bit more detail in case you're interested or want to change from the defaults."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The Cache Loader configuration for the <literal>standard-session-cache</literal> config serves as a good example:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<property name=\"cacheLoaderConfig\">\n"
+" <bean class=\"org.jboss.cache.config.CacheLoaderConfig\">\n"
+" <!-- Do not change these -->\n"
+" <property name=\"passivation\">true</property>\n"
+" <property name=\"shared\">false</property>\n"
+" \n"
+" <property name=\"individualCacheLoaderConfigs\">\n"
+" <list>\n"
+" <bean class=\"org.jboss.cache.loader.FileCacheLoaderConfig\">\n"
+" <!-- Where passivated sessions are stored -->\n"
+" <property name=\"location\">${jboss.server.data.dir}${/}session</property>\n"
+" <!-- Do not change these -->\n"
+" <property name=\"async\">false</property>\n"
+" <property name=\"fetchPersistentState\">true</property>\n"
+" <property name=\"purgeOnStartup\">true</property>\n"
+" <property name=\"ignoreModifications\">false</property>\n"
+" <property name=\"checkCharacterPortability\">false</property>\n"
+" </bean>\n"
+" </list>\n"
+" </property>\n"
+" </bean>\n"
+"</property>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Some explanation:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">passivation</emphasis> property MUST be <literal>true</literal>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">shared</emphasis> property MUST be <literal>false</literal>. Do not passivate sessions to a shared persistent store, otherwise if another node activates the session, it will be gone from the persistent store and also gone from memory on other nodes that have passivated it. Backup copies will be lost."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">individualCacheLoaderConfigs</emphasis> property accepts a list of Cache Loader configurations. JBC allows you to chain cache loaders; see the JBoss Cache docs. For the session passivation use case a single cache loader is sufficient."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">class</emphasis> attribute on a cache loader config bean must refer to the configuration class for a cache loader implementation (e.g. <literal>org.jboss.cache.loader.FileCacheLoaderConfig</literal> or <literal>org.jboss.cache.loader.JDBCCacheLoaderConfig</literal>). See the JBoss Cache documentation for more on the available CacheLoader implementations. If you wish to use JDBCCacheLoader (to persist to a database rather than the filesystem used by FileCacheLoader) note the comment above about the <literal>shared</literal> property. Don't use a shared database, or at least not a shared table in the database. Each node in the cluster must have its own storage location."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">location</emphasis> property for FileCacheLoaderConfig defines the root node of the filesystem tree where passivated sessions should be stored. The default is to store them in your JBoss Enterprise Application Platform configuration's <literal>data</literal> directory."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">async</emphasis> MUST be <literal>false</literal> to ensure passivated sessions are promptly written to the persistent store."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">fetchPersistentState</emphasis> property MUST be <literal>true</literal> to ensure passivated sessions are included in the set of session backup copies transferred over from other nodes when the cache starts."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">purgeOnStartup</emphasis> should be <literal>true</literal> to ensure out-of-date session data left over from a previous shutdown of a server doesn't pollute the current data set."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">ignoreModifications</emphasis> should be <literal>false</literal>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">checkCharacterPortability</emphasis> should be <literal>false</literal> as a minor performance optimization."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Buddy Replication"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Buddy Replication is a JBoss Cache feature that allows you to suppress replicating your data to all instances in a cluster. Instead, each instance picks one or more 'buddies' in the cluster, and only replicates to those specific buddies. This greatly helps scalability as there is no longer a memory and network traffic impact every time another instance is added to a cluster."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If the cache on another node needs data that it doesn't have locally, it can ask the other nodes in the cluster to provide it; nodes that have a copy will provide it as part of a process called \"data gravitation\". The new node will become the owner of the data, placing a backup copy of the data on its buddies. The ability to gravitate data means there is no need for all requests for data to occur on a node that has a copy of it; any node can handle a request for any data. However, data gravitation is expensive and should not be a frequent occurence; ideally it should only occur if the node that is using some data fails or is shut down, forcing interested clients to fail over to a different node. This makes buddy replication primarily useful for session-type applications with session affinity (a.k.a. \"sticky sessions\") where all requests for a particular session are normally handled by a single server."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Buddy replication can be enabled for the web session and EJB3 SFSB caches. Do not add buddy replication to the cache configurations used for other standard clustering services (e.g. JPA/Hibernate caching). Services not specifically engineered for buddy replication are highly unlikely to work correctly if it is introduced."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Configuring buddy replication is fairly straightforward. As an example we'll look at the buddy replication configuration section from the CacheManager service's <literal>standard-session-cache</literal> config:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<property name=\"buddyReplicationConfig\">\n"
+" <bean class=\"org.jboss.cache.config.BuddyReplicationConfig\">\n"
+" \n"
+" <!-- Just set to true to turn on buddy replication -->\n"
+" <property name=\"enabled\">true</property>\n"
+" \n"
+" <!-- A way to specify a preferred replication group. We try\n"
+" and pick a buddy who shares the same pool name (falling \n"
+" back to other buddies if not available). -->\n"
+" <property name=\"buddyPoolName\">default</property>\n"
+" \n"
+" <property name=\"buddyCommunicationTimeout\">17500</property>\n"
+" \n"
+" <!-- Do not change these -->\n"
+" <property name=\"autoDataGravitation\">false</property>\n"
+" <property name=\"dataGravitationRemoveOnFind\">true</property>\n"
+" <property name=\"dataGravitationSearchBackupTrees\">true</property>\n"
+" \n"
+" <property name=\"buddyLocatorConfig\">\n"
+" <bean class=\"org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig\">\n"
+" <!-- The number of backup copies we maintain -->\n"
+" <property name=\"numBuddies\">1</property>\n"
+" <!-- Means that each node will *try* to select a buddy on \n"
+" a different physical host. If not able to do so \n"
+" though, it will fall back to colocated nodes. -->\n"
+" <property name=\"ignoreColocatedBuddies\">true</property>\n"
+" </bean>\n"
+" </property>\n"
+" </bean>\n"
+"</property>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The main things you would be likely to configure are:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">buddyReplicationEnabled</emphasis> — <literal>true</literal> if you want buddy replication; <literal>false</literal> if data should be replicated to all nodes in the cluster, in which case none of the other buddy replication configurations matter."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">numBuddies</emphasis> — to how many backup nodes should each node replicate its state."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">buddyPoolName</emphasis> — allows logical subgrouping of nodes within the cluster; if possible, buddies will be chosen from nodes in the same buddy pool."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>ignoreColocatedBuddies</literal> switch means that when the cache is trying to find a buddy, it will if possible not choose a buddy on the same physical host as itself. If the only server it can find is running on its own machine, it will use that server as a buddy."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Do not change the settings for <literal>autoDataGravitation</literal>, <literal>dataGravitationRemoveOnFind</literal> and <literal>dataGravitationSearchBackupTrees</literal>. Session replication will not work properly if these are changed."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Deploying Your Own JBoss Cache Instance"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "It's quite common for users to deploy their own instances of JBoss Cache inside JBoss Enterprise Application Platform for custom use by their applications. In this section we describe the various ways caches can be deployed."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Deployment Via the CacheManager Service"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The standard JBoss clustered services that use JBoss Cache obtain a reference to their cache from the Enterprise Application Platform's CacheManager service (see <xref linkend=\"clustering-blocks-jbc-cachemanager\" />). End user applications can do the same thing; here's how."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<xref linkend=\"jbosscache-configuration-cachemanager\" /> shows the configuration of the CacheManager's \"CacheConfigurationRegistry\" bean. To add a new configuration, you would add an additional element inside that bean's <literal>newConfigurations</literal> <map>:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"CacheConfigurationRegistry\" \n"
+" class=\"org.jboss.ha.cachemanager.DependencyInjectedConfigurationRegistry\">\n"
+" .....\n"
+" <property name=\"newConfigurations\">\n"
+" <map keyClass=\"java.lang.String\" valueClass=\"org.jboss.cache.config.Configuration\">\n"
+" \n"
+" <entry><key>my-custom-cache</key>\n"
+" <value> \n"
+" <bean name=\"MyCustomCacheConfig\" class=\"org.jboss.cache.config.Configuration\"> \n"
+" .... details of the my-custom-cache configuration\n"
+" </bean> \n"
+" </value>\n"
+" </entry> \n"
+" .....\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "See <xref linkend=\"jbosscache-configuration-cachemanager\" /> for an example configuration."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Accessing the CacheManager"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Once you've added your cache configuration to the CacheManager, the next step is to provide a reference to the CacheManager to your application. There are three ways to do this:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">Dependency Injection</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your application uses the JBoss Microcontainer for configuration, the simplest mechanism is to have it inject the CacheManager into your service."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<bean name=\"MyService\" class=\"com.example.MyService\">\n"
+" <property name=\"cacheManager\"><inject bean=\"CacheManager\"/></property>\n"
+"</bean>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">JNDI Lookup</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Alternatively, you can find look up the CacheManger is JNDI. It is bound under <literal>java:CacheManager</literal>."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"import org.jboss.ha.cachemanager.CacheManager;\n"
+"\n"
+"public class MyService {\n"
+" private CacheManager cacheManager;\n"
+" \n"
+" public void start() throws Exception {\n"
+" Context ctx = new InitialContext();\n"
+" cacheManager = (CacheManager) ctx.lookup(\"java:CacheManager\");\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">CacheManagerLocator</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform also provides a service locator object that can be used to access the CacheManager."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"import org.jboss.ha.cachemanager.CacheManager;\n"
+"import org.jboss.ha.framework.server.CacheManagerLocator;\n"
+"\n"
+"public class MyService {\n"
+" private CacheManager cacheManager;\n"
+" \n"
+" public void start() throws Exception {\n"
+" CacheManagerLocator locator = CacheManagerLocator.getCacheManagerLocator();\n"
+" // Locator accepts as param a set of JNDI properties to help in lookup;\n"
+" // this isn't necessary inside the Enterprise Application Platform\n"
+" cacheManager = locator.getCacheManager(null);\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Once a reference to the CacheManager is obtained; usage is simple. Access a cache by passing in the name of the desired configuration. The CacheManager will not start the cache; this is the responsibility of the application. The cache may, however, have been started by another application running in the cache server; the cache may be shared. When the application is done using the cache, it should not stop. Just inform the CacheManager that the cache is no longer being used; the manager will stop the cache when all callers that have asked for the cache have released it."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"import org.jboss.cache.Cache;\n"
+"import org.jboss.ha.cachemanager.CacheManager;\n"
+"import org.jboss.ha.framework.server.CacheManagerLocator;\n"
+"\n"
+"public class MyService {\n"
+" private CacheManager cacheManager;\n"
+" private Cache cache;\n"
+" \n"
+" public void start() throws Exception {\n"
+" Context ctx = new InitialContext();\n"
+" cacheManager = (CacheManager) ctx.lookup(\"java:CacheManager\");\n"
+" \n"
+" // \"true\" param tells the manager to instantiate the cache if\n"
+" // it doesn't exist yet\n"
+" cache = cacheManager.getCache(\"my-cache-config\", true);\n"
+" \n"
+" cache.start();\n"
+" }\n"
+" \n"
+" public void stop() throws Exception {\n"
+" cacheManager.releaseCache(\"my-cache-config\");\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The CacheManager can also be used to access instances of POJO Cache."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"import org.jboss.cache.pojo.PojoCache;\n"
+"import org.jboss.ha.cachemanager.CacheManager;\n"
+"import org.jboss.ha.framework.server.CacheManagerLocator;\n"
+"\n"
+"public class MyService {\n"
+" private CacheManager cacheManager;\n"
+" private PojoCache pojoCache;\n"
+" \n"
+" public void start() throws Exception {\n"
+" Context ctx = new InitialContext();\n"
+" cacheManager = (CacheManager) ctx.lookup(\"java:CacheManager\");\n"
+" \n"
+" // \"true\" param tells the manager to instantiate the cache if\n"
+" // it doesn't exist yet\n"
+" pojoCache = cacheManager.getPojoCache(\"my-cache-config\", true);\n"
+" \n"
+" pojoCache.start();\n"
+" }\n"
+" \n"
+" public void stop() throws Exception {\n"
+" cacheManager.releasePojoCache(\"my-cache-config\");\n"
+" }\n"
+"}"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Deployment Via a <literal>-service.xml</literal> File"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "As in JBoss 4.x, you can also deploy a JBoss Cache instance as an MBean service via a <literal>-service.xml</literal> file. The primary difference from JBoss 4.x is the value of the <literal>code</literal> attribute in the <literal>mbean</literal> element. In JBoss 4.x, this was <literal>org.jboss.cache.TreeCache</literal>; in JBoss 5.x it is <literal>org.jboss.cache.jmx.CacheJmxWrapper</literal>. Here's an example:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+"\n"
+"<server>\n"
+" <mbean code=\"org.jboss.cache.jmx.CacheJmxWrapper\" \n"
+" name=\"foo:service=ExampleCacheJmxWrapper\">\n"
+" \n"
+" <attribute name=\"TransactionManagerLookupClass\">\n"
+" org.jboss.cache.transaction.JBossTransactionManagerLookup\n"
+" </attribute>\n"
+" \n"
+" <attribute name=\"MuxChannelFactory\"><inject bean=\"JChannelFactory\"/></attribute>\n"
+" \n"
+" <attribute name=\"MultiplexerStack\">udp</attribute>\n"
+" <attribute name=\"ClusterName\">Example-EntityCache</attribute> \n"
+" <attribute name=\"IsolationLevel\">REPEATABLE_READ</attribute>\n"
+" <attribute name=\"CacheMode\">REPL_SYNC</attribute>\n"
+" <attribute name=\"InitialStateRetrievalTimeout\">15000</attribute>\n"
+" <attribute name=\"SyncReplTimeout\">20000</attribute>\n"
+" <attribute name=\"LockAcquisitionTimeout\">15000</attribute>\n"
+" <attribute name=\"ExposeManagementStatistics\">true</attribute>\n"
+" \n"
+" </mbean>\n"
+"</server>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>CacheJmxWrapper</literal> is not the cache itself (i.e. you can't store stuff in it). Rather, as it's name implies, it's a wrapper around an <literal>org.jboss.cache.Cache</literal> that handles integration with JMX. <literal>CacheJmxWrapper</literal> exposes the <literal>org.jboss.cache.Cache</literal> via its <literal>CacheJmxWrapperMBean</literal> MBean interfaces <literal>Cache</literal> attribute; services that need the cache can obtain a reference to it via that attribute."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Deployment Via a <literal>-jboss-beans.xml</literal> File"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Much like it can deploy MBean services described with a <literal>-service.xml</literal>, JBoss Enterprise Application Platform 5 can also deploy services that consist of Plain Old Java Objects (POJOs) if the POJOs are described using the JBoss Microcontainer schema in a <literal>-jboss-beans.xml</literal> file. You create such a file and deploy it, either directly in the <literal>deploy</literal> dir, or packaged in an ear or sar. Following is an example:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+"\n"
+"<deployment xmlns=\"urn:jboss:bean-deployer:2.0\">\n"
+"\n"
+" <!-- First we create a Configuration object for the cache -->\n"
+" <bean name=\"ExampleCacheConfig\"\n"
+" class=\"org.jboss.cache.config.Configuration\">\n"
+"\n"
+" <!-- Externally injected services --> \n"
+" <property name=\"runtimeConfig\">\n"
+" <bean name=\"ExampleCacheRuntimeConfig\" class=\"org.jboss.cache.config.RuntimeConfig\">\n"
+" <property name=\"transactionManager\">\n"
+" <inject bean=\"jboss:service=TransactionManager\" \n"
+" property=\"TransactionManager\"/>\n"
+" </property>\n"
+" <property name=\"muxChannelFactory\"><inject bean=\"JChannelFactory\"/></property>\n"
+" </bean>\n"
+" </property>\n"
+" \n"
+" <property name=\"multiplexerStack\">udp</property>\n"
+" <property name=\"clusterName\">Example-EntityCache</property> \n"
+" <property name=\"isolationLevel\">REPEATABLE_READ</property>\n"
+" <property name=\"cacheMode\">REPL_SYNC</property>\n"
+" <property name=\"initialStateRetrievalTimeout\">15000</property>\n"
+" <property name=\"syncReplTimeout\">20000</property>\n"
+" <property name=\"lockAcquisitionTimeout\">15000</property>\n"
+" <property name=\"exposeManagementStatistics\">true</property>\n"
+"\n"
+" </bean>\n"
+" \n"
+" <!-- Factory to build the Cache. -->\n"
+" <bean name=\"DefaultCacheFactory\" class=\"org.jboss.cache.DefaultCacheFactory\"> \n"
+" <constructor factoryClass=\"org.jboss.cache.DefaultCacheFactory\" />\n"
+" </bean>\n"
+" \n"
+" <!-- The cache itself -->\n"
+" <bean name=\"ExampleCache\" class=\"org.jboss.cache.Cache\">\n"
+" <constructor factoryMethod=\"createCache\">\n"
+" <factory bean=\"DefaultCacheFactory\"/>\n"
+" <parameter class=\"org.jboss.cache.config.Configuration\"><inject bean=\"ExampleCacheConfig\"/></parameter>\n"
+" <parameter class=\"boolean\">false</false>\n"
+" </constructor>\n"
+" </bean>\n"
+" \n"
+" <bean name=\"ExampleService\" class=\"org.foo.ExampleService\">\n"
+" <property name=\"cache\"><inject bean=\"ExampleCache\"/></property>\n"
+" </bean>\n"
+"\n"
+"</deployment>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The bulk of the above is the creation of a JBoss Cache <literal>Configuration</literal> object; this is the same as what we saw in the configuration of the CacheManager service (see <xref linkend=\"jbosscache-configuration-cachemanager\" />). In this case we're not using the CacheManager service as a cache factory, so instead we create our own factory bean and then use it to create the cache (the \"ExampleCache\" bean). The \"ExampleCache\" is then injected into a (fictitious) service that needs it."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "An interesting thing to note in the above example is the use of the <literal>RuntimeConfig</literal> object. External resources like a <literal>TransactionManager</literal> and a JGroups <literal>ChannelFactory</literal> that are visible to the microcontainer are dependency injected into the <literal>RuntimeConfig</literal>. The assumption here is that in some other deployment descriptor in the Enterprise Application Platform, the referenced beans have already been described."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Using the configuration above, the \"ExampleCache\" cache will not be visible in JMX. Here's an alternate approach that results in the cache being bound into JMX:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+"\n"
+"<deployment xmlns=\"urn:jboss:bean-deployer:2.0\">\n"
+"\n"
+" <!-- First we create a Configuration object for the cache -->\n"
+" <bean name=\"ExampleCacheConfig\"\n"
+" class=\"org.jboss.cache.config.Configuration\">\n"
+"\n"
+" .... same as above\n"
+"\n"
+" </bean>\n"
+" \n"
+" <bean name=\"ExampleCacheJmxWrapper\" class=\"org.jboss.cache.jmx.CacheJmxWrapper\">\n"
+" \n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"foo:service=ExampleCacheJmxWrapper\",\n"
+" exposedInterface=org.jboss.cache.jmx.CacheJmxWrapperMBean.class, \n"
+" registerDirectly=true)\n"
+" </annotation>\n"
+" \n"
+" <property name=\"configuration\"><inject bean=\"ExampleCacheConfig\"/></property>\n"
+" \n"
+" </bean>\n"
+" \n"
+" <bean name=\"ExampleService\" class=\"org.foo.ExampleService\">\n"
+" <property name=\"cache\"><inject bean=\"ExampleCacheJmxWrapper\" property=\"cache\"/></property>\n"
+" </bean>\n"
+"\n"
+"</deployment>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Here the \"ExampleCacheJmxWrapper\" bean handles the task of creating the cache from the configuration. <literal>CacheJmxWrapper</literal> is a JBoss Cache class that provides an MBean interface for a cache. Adding an <annotation> element binds the JBoss Microcontainer <literal>@JMX</literal> annotation to the bean; that in turn results in JBoss Enterprise Application Platform registering the bean in JXM as part of the deployment process."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The actual underlying <literal>org.jboss.cache.Cache</literal> instance is available from the <literal>CacheJmxWrapper</literal> via its <literal>cache</literal> property; the example shows how this can be used to inject the cache into the \"ExampleService\"."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JGroups.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JGroups.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Clustering_Guide_JGroups.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,1740 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "JGroups Services"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JGroups provides the underlying group communication support for JBoss Enterprise Application Platform clusters. The interaction of clustered services with JGroups was covered in <xref linkend=\"clustering-blocks-jgroups\" />. This chapter focuses on the details of this interaction, with particular attention to configuration details and troubleshooting tips."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This chapter is not intended as complete JGroups documentation. If you want to know more about JGroups, you can consult:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JGroups project documentation at <ulink url=\"http://jgroups.org/ug.html\">http://jgroups.org/ug.html</ulink>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JGroups wiki pages at jboss.org, rooted at <ulink url=\"https://www.jboss.org/community/wiki/JGroups\">https://www.jboss.org/community/wiki/JGroups</ulink>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The first section of this chapter covers the many JGroups configuration options in detail. JBoss Enterprise Application Platform ships with a set of default JGroups configurations. Most applications will work with the default configurations out of the box. You will only need to edit these configurations when you deploy an application with special network or performance requirements."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Configuring a JGroups Channel's Protocol Stack"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JGroups framework provides services to enable peer-to-peer communications between nodes in a cluster. Communication occurs over a communication channel. The channel built up from a stack of network communication <emphasis>protocols</emphasis>, each of which is responsible for adding a particular capability to the overall behavior of the channel. Key capabilities provided by various protocols include transport, cluster discovery, message ordering, lossless message delivery, detection of failed peers, and cluster membership management services."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<xref linkend=\"JGroupsStack.fig\" /> shows a conceptual cluster with each member's channel composed of a stack of JGroups protocols."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Protocol stack in JGroups"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This section of the chapter covers some of the most commonly used protocols, according to the type of behaviour they add to the channel. We discuss a few key configuration attributes exposed by each protocol, but since these attributes should be altered only by experts, this chapter focuses on familiarizing users with the purpose of various protocols."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JGroups configurations used in JBoss Enterprise Application Platform appear as nested elements in the <filename>$JBOSS_HOME/server/all/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename> file. This file is parsed by the <literal>ChannelFactory</literal> service, which uses the contents to provide correctly configured channels to the clustered services that require them. See <xref linkend=\"clustering-blocks-jgroups-channelfactory\" /> for more on the <literal>ChannelFactory</literal> service."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following is an example protocol stack configuration from <filename>jgroups-channelfactory-stacks.xml</filename>:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<stack name=\"udp-async\"\n"
+" description=\"Same as the default 'udp' stack above, except message bundling\n"
+" is enabled in the transport protocol (enable_bundling=true). \n"
+" Useful for services that make high-volume asynchronous \n"
+" RPCs (e.g. high volume JBoss Cache instances configured \n"
+" for REPL_ASYNC) where message bundling may improve performance.\">\n"
+" <config>\n"
+" <UDP\n"
+" singleton_name=\"udp-async\"\n"
+" mcast_port=\"${jboss.jgroups.udp_async.mcast_port:45689}\"\n"
+" mcast_addr=\"${jboss.partition.udpGroup:228.11.11.11}\"\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=\"true\"\n"
+" discard_incompatible_packets=\"true\"\n"
+" enable_bundling=\"true\"\n"
+" max_bundle_size=\"64000\"\n"
+" max_bundle_timeout=\"30\"\n"
+" ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
+" thread_naming_pattern=\"cl\"\n"
+" timer.num_threads=\"12\"\n"
+" enable_diagnostics=\"${jboss.jgroups.enable_diagnostics:true}\"\n"
+" diagnostics_addr=\"${jboss.jgroups.diagnostics_addr:224.0.0.75}\"\n"
+" diagnostics_port=\"${jboss.jgroups.diagnostics_port:7500}\"\n"
+"\n"
+" thread_pool.enabled=\"true\"\n"
+" thread_pool.min_threads=\"8\"\n"
+" thread_pool.max_threads=\"200\"\n"
+" thread_pool.keep_alive_time=\"5000\"\n"
+" thread_pool.queue_enabled=\"true\"\n"
+" thread_pool.queue_max_size=\"1000\"\n"
+" thread_pool.rejection_policy=\"discard\"\n"
+" \n"
+" oob_thread_pool.enabled=\"true\"\n"
+" oob_thread_pool.min_threads=\"8\"\n"
+" oob_thread_pool.max_threads=\"200\"\n"
+" oob_thread_pool.keep_alive_time=\"1000\"\n"
+" oob_thread_pool.queue_enabled=\"false\"\n"
+" oob_thread_pool.rejection_policy=\"discard\"/>\n"
+" <PING timeout=\"2000\" num_initial_members=\"3\"/>\n"
+" <MERGE2 max_interval=\"100000\" min_interval=\"20000\"/>\n"
+" <FD_SOCK/>\n"
+" <FD timeout=\"6000\" max_tries=\"5\" shun=\"true\"/>\n"
+" <VERIFY_SUSPECT timeout=\"1500\"/>\n"
+" <BARRIER/>\n"
+" <pbcast.NAKACK use_mcast_xmit=\"true\" gc_lag=\"0\"\n"
+" retransmit_timeout=\"300,600,1200,2400,4800\"\n"
+" discard_delivered_msgs=\"true\"/>\n"
+" <UNICAST timeout=\"300,600,1200,2400,3600\"/>\n"
+" <pbcast.STABLE stability_delay=\"1000\" desired_avg_gossip=\"50000\"\n"
+" max_bytes=\"400000\"/> \n"
+" <VIEW_SYNC avg_send_interval=\"10000\"/>\n"
+" <pbcast.GMS print_local_addr=\"true\" join_timeout=\"3000\"\n"
+" shun=\"true\"\n"
+" view_bundling=\"true\"\n"
+" view_ack_collection_timeout=\"5000\"\n"
+" resume_task_timeout=\"7500\"/>\n"
+" <FC max_credits=\"2000000\" min_threshold=\"0.10\" \n"
+" ignore_synchronous_response=\"true\"/>\n"
+" <FRAG2 frag_size=\"60000\"/>\n"
+" <!-- pbcast.STREAMING_STATE_TRANSFER/ -->\n"
+" <pbcast.STATE_TRANSFER/>\n"
+" <pbcast.FLUSH timeout=\"0\" start_flush_timeout=\"10000\"/>\n"
+" </config>\n"
+" </stack> \n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal><config></literal> element contains all the configuration data for JGroups. This information is used to configure a JGroups <emphasis>channel</emphasis>, which is conceptually similar to a socket, and manages communication between peers in a cluster. Each element within the <literal><config></literal> element defines a particular JGroups <emphasis>protocol</emphasis>. Each protocol performs one function. The combination of these functions defines the characteristics of the channel as a whole. The next few sections describe common protocols and explain the options available to each."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Common Configuration Properties"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following property is exposed by all of the JGroups protocols discussed below:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>stats</literal> whether the protocol should gather runtime statistics on its operations that can be exposed via tools like the AS's JMX console or the JGroups Probe utility. What, if any, statistics are gathered depends on the protocol. Default is <literal>true</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "All of the protocols in the versions of JGroups used in JBoss Application Server 3.x and 4.x exposed <literal>down_thread</literal> and <literal>up_thread</literal> attributes. The JGroups version included in JBoss Application Server 5 and later no longer uses those attributes, and a <literal>WARN</literal> message will be written to the server log if they are configured for any protocol."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Transport Protocols"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The transport protocols send and receive messages to and from the network. They also manage the thread pools used to deliver incoming messages to addresses higher in the protocol stack. JGroups supports <literal>UDP</literal>, <literal>TCP</literal> and <literal>TUNNEL</literal> as transport protocols."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>UDP</literal>, <literal>TCP</literal>, and <literal>TUNNEL</literal> protocols are mutually exclusive. You can only have one transport protocol in each JGroups <literal>Config</literal> element"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "UDP configuration"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "UDP is the preferred transport protocol for JGroups. UDP uses multicast (or, in an unusual configuration, 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
+#, no-c-format
+msgid " <UDP\n"
+" singleton_name=\"udp-async\"\n"
+" mcast_port=\"${jboss.jgroups.udp_async.mcast_port:45689}\"\n"
+" mcast_addr=\"${jboss.partition.udpGroup:228.11.11.11}\"\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=\"true\"\n"
+" discard_incompatible_packets=\"true\"\n"
+" enable_bundling=\"true\"\n"
+" max_bundle_size=\"64000\"\n"
+" max_bundle_timeout=\"30\"\n"
+" ip_ttl=\"${jgroups.udp.ip_ttl:2}\"\n"
+" thread_naming_pattern=\"cl\"\n"
+" timer.num_threads=\"12\"\n"
+" enable_diagnostics=\"${jboss.jgroups.enable_diagnostics:true}\"\n"
+" diagnostics_addr=\"${jboss.jgroups.diagnostics_addr:224.0.0.75}\"\n"
+" diagnostics_port=\"${jboss.jgroups.diagnostics_port:7500}\"\n"
+"\n"
+" thread_pool.enabled=\"true\"\n"
+" thread_pool.min_threads=\"8\"\n"
+" thread_pool.max_threads=\"200\"\n"
+" thread_pool.keep_alive_time=\"5000\"\n"
+" thread_pool.queue_enabled=\"true\"\n"
+" thread_pool.queue_max_size=\"1000\"\n"
+" thread_pool.rejection_policy=\"discard\"\n"
+" \n"
+" oob_thread_pool.enabled=\"true\"\n"
+" oob_thread_pool.min_threads=\"8\"\n"
+" oob_thread_pool.max_threads=\"200\"\n"
+" oob_thread_pool.keep_alive_time=\"1000\"\n"
+" oob_thread_pool.queue_enabled=\"false\"\n"
+" oob_thread_pool.rejection_policy=\"discard\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JGroups transport configurations have a number of attributes available. First we look at the attributes available to the <literal>UDP</literal> protocol, followed by the attributes that are also used by the <literal>TCP</literal> and <literal>TUNNEL</literal> transport protocols."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The attributes particular to the <literal>UDP</literal> protocol are:"
+msgstr ""
+
+#. Tag: para
+#, 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 <literal>false</literal>, multiple unicast packets will be sent instead of one multicast packet. Any packet sent via <literal>UDP</literal> protocol are UDP datagrams."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mcast_addr</emphasis> specifies the multicast address (class D) for communicating with the group (i.e., the cluster). The standard protocol stack configurations in JBoss AS use the value of system property <literal>jboss.partition.udpGroup</literal>, if set, as the value for this attribute. Using the <literal>-u</literal> command line switch when starting JBoss Application Server sets that value. See <xref linkend=\"clustering-jgroups-isolation\" /> for information about using this configuration attribute to ensure that JGroups channels are properly isolated from one another. If this attribute is omitted, the default value is <literal>228.11.11.11</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">mcast_port</emphasis> specifies the port to use for multicast communication with the group. See <xref linkend=\"clustering-jgroups-isolation\" /> for how to use this configuration attribute to ensure JGroups channels are properly isolated from one another. If this attribute is omitted, the default is <literal>45688</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>mcast_send_buf_size</literal>, <literal>mcast_recv_buf_size</literal>, <literal>ucast_send_buf_size</literal> and <literal>ucast_recv_buf_size</literal> define the socket send and receive buffer sizes that JGroups will request from the operating system. A large buffer size helps to ensure that packets are not dropped due to buffer overflow. However, socket buffer sizes are limited at the operating system level, so obtaining the desired buffer may require configuration at the operating system level. See <xref linkend=\"jgroups-perf-udpbuffer\" /> for further details."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">bind_port</emphasis> specifies the port to which the unicast receive socket should be bound. The default is <literal>0</literal>; i.e. use an ephemeral port."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">port_range</emphasis> specifies the number of ports to try if the port identified by <literal>bind_port</literal> is not available. The default is <literal>1</literal>, which specifies that only <literal>bind_port</literal> will be tried."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">ip_ttl</emphasis> specifies time-to-live (TTL) 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">tos</emphasis> specifies the traffic class for sending unicast and multicast datagrams."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The attributes that are common to all transport protocols, and thus have the same meanings when used with <literal>TCP</literal> or <literal>TUNNEL</literal>, are:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">singleton_name</emphasis> provides a unique name for this transport protocol configuration. Used by the application server's <literal>ChannelFactory</literal> to support sharing of a transport protocol instance by different channels that use the same transport protocol configuration. See <xref linkend=\"clustering-blocks-jgroups-sharedtransport\" />."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on which to receive and send messages. By default, JGroups uses the value of system property <literal>jgroups.bind_addr</literal>. This can also be set with the <literal>-b</literal> command line switch. See <xref linkend=\"jgroups-other\" /> for more on binding JGroups sockets."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">send_on_all_interfaces</emphasis> specifies whether this node sends UDP packets via all available network interface controllers, if your machine has multiple network interface controllers available. This means that the same multicast message is sent N times, so use with care."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">receive_interfaces</emphasis> specifies a list of of interfaces on which to receive multicasts. The multicast receive socket will listen on all of these interfaces. This is a comma-separated list of IP addresses or interface names, for example, <literal>192.168.5.1,eth1,127.0.0.1</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">send_interfaces</emphasis> specifies a list of of interfaces via which to send multicasts. The multicast sender socket will send on all of these interfaces. This is a comma-separated list of IP addresses or interface names, for example, <literal>192.168.5.1,eth1,127.0.0.1</literal>.This means that the same multicast message is sent N times, so use with care."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">enable_bundling</emphasis> specifies whether to enable message bundling. If <literal>true</literal>, the tranpsort protocol queues outgoing messages until <literal>max_bundle_size</literal> bytes have accumulated, or <literal>max_bundle_time</literal> milliseconds have elapsed, whichever occurs first. Then the transport protocol bundles queued messages into one large message and sends it. The messages are unbundled at the receiver. The default is <literal>false</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Message bundling can have significant performance benefits for channels that are used for high volume sending of messages where the sender does not block waiting for a response from recipients (for example, a JBoss Cache instance configured for <literal>REPL_ASYNC</literal>.) It can add considerable latency to applications where senders need to block waiting for responses, so it is not recommended for certain situations, such as where a JBoss Cache instance is configured for <literal>REPL_SYNC</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">loopback</emphasis> specifies whether the thread sending a message to the group should itself carry the message back up the stack for delivery. (Messages sent to the group are always delivered to the sending node as well.) If <literal>false</literal>, the sending thread does not carry the message; the transport protocol waits to read the message off the network and uses one of the message delivery pool threads for delivery. The default is <literal>false</literal>, but <literal>true</literal> is recommended to ensure that the channel receives its own messages, in case the network interface goes down."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">discard_incompatible_packets</emphasis> specifies whether to discard packets sent by peers that use a different version of JGroups. Each message in the cluster is tagged with a JGroups version. If <literal>discard_incompatible_packets</literal> is set to <literal>true</literal>, messages received from different versions of JGroups will be silently discarded. Otherwise, a warning will be logged. <emphasis>In no case will the message be delivered.</emphasis> The default value is <literal>false</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">enable_diagnostics</emphasis> specifies that the transport should open a multicast socket on address <literal>diagnostics_addr</literal> and port <literal>diagnostics_port</literal> to listen for diagnostic requests sent by the JGroups <ulink url=\"http://www.jboss.org/community/wiki/Probe\"><emphasis role=\"bold\">Probe</emphasis> utility</ulink>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The various <emphasis role=\"bold\">thread_pool</emphasis> attributes configure the behavior of the pool of threads JGroups uses to carry ordinary incoming messages up the stack. The various attributes provide the constructor arguments for an instance of <literal>java.util.concurrent.ThreadPoolExecutorService</literal>. In the example above, the pool will have a minimum or <emphasis>core size</emphasis> of 8 threads, and a maximum size of 200. If more than 8 pool threads have been created, a thread returning from carrying a message will wait for up to 5000 milliseconds to be assigned a new message to carry, after which it will terminate. If no threads are available to carry a message, the (separate) thread reading messages off the socket will place messages in a queue; the queue will hold up to 1000 messages. If the queue is full, the thread reading messages off the socket will discard the message."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The various <emphasis role=\"bold\">oob_thread_pool</emphasis> attributes are similar to the <emphasis role=\"bold\">thread_pool</emphasis> attributes in that they configure a <literal>java.util.concurrent.ThreadPoolExecutorService</literal> used to carry incoming messages up the protocol stack. In this case, the pool is used to carry a special type of message known as an Out-Of-Band (OOB) message. OOB messages are exempt from the ordered-delivery requirements of protocols like NAKACK and UNICAST and thus can be delivered up the stack even if NAKACK or UNICAST are queueing up messages from a particular sender. OOB messages are often used internally by JGroups protocols and can be used by applications as well. For example, when JBoss Cache is in <literal>REPL_SYNC</literal> mode, it uses OOB messages for the second phase of its two-phase-commit protocol."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "TCP configuration"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "\n"
+"<TCP singleton_name=\"tcp\" \n"
+" start_port=\"7800\" end_port=\"7800\"/>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The following attributes are specific to the <literal>TCP</literal> element:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>start_port</literal> and <literal>end_port</literal> define the range of TCP ports to which the server should bind. The server socket is bound to the first available port beginning with <literal>start_port</literal>. If no available port is found (for example, because the ports are in use by other sockets) before the <literal>end_port</literal>, the server throws an exception. If no <literal>end_port</literal> is provided, or <literal>end_port</literal> is lower than <literal>start_port</literal>, no upper limit is applied to the port range. If <literal>start_port</literal> is equal to <literal>end_port</literal>, JGroups is forced to use the specified port, since <literal>start_port</literal> fails if the specified port in not available. The default value is <literal>7800</literal>. If set to <literal>0</literal>, the operating system will select a port. (This will only work for <literal>MPING</literal> or <literal>TCPGOSSIP</literal> discovery protocols. <!
literal>TCCPING</literal> requires that nodes and their required ports are listed.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">bind_port</emphasis> in TCP acts as an alias for <literal>start_port</literal>. If configured internally, it sets <literal>start_port</literal>."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, 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
+#, 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
+#, 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
+#, 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
+#, 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
+#, 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: para
+#, no-c-format
+msgid "All of the attributes common to all protocols discussed in the UDP protocol section also apply to TCP."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "TUNNEL configuration"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>TUNNEL</literal> protocol uses an external router process to send messages. The external router is a Java process that runs the <literal>org.jgroups.stack.GossipRouter</literal> main class. 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 set up communication with nodes behind firewalls. A node can establish a TCP connection to the <classname>GossipRouter</classname> through the firewall (you can use port 80). This connection is also 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 <literal>TUNNEL</literal> configuration is defined in the <literal>TUNNEL</literal> element within the JGroups <literal><config></literal> element, like so:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<TUNNEL singleton_name=\"tunnel\"\n"
+" router_port=\"12001\"\n"
+" router_host=\"192.168.5.1\"/>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>TUNNEL</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">router_host</emphasis> specifies the host on which the GossipRouter is running."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">router_port</emphasis> specifies the port on which the GossipRouter is listening."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">reconnect_interval</emphasis> specifies the interval of time (in milliseconds) for which <literal>TUNNEL</literal> will attempt to connect to the <classname>GossipRouter</classname> if the connection is not established. The default value is <literal>5000</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "All of the attributes common to all protocols discussed in the UDP protocol section also apply to <literal>TUNNEL</literal>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Discovery Protocols"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "When a channel on a node first connects, it must determine which other nodes are running compatible channels, and which of these nodes is currently acting as the <emphasis>coordinator</emphasis> (the node responsible for letting new nodes join the group). Discovery protocols are used to find active nodes in the cluster and to determine which is the coordinator. This information is then provided to the group membership protocol (GMS), which communicates with the coordinator's GMS to add the newly-connecting node to the group. (For more information about group membership protocols, see <xref linkend=\"jgroups-other-gms\" />.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Discovery protocols also assist merge protocols (see <xref linkend=\"jgroups-other-merge\" />) to detect cluster-split situations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The discovery protocols sit on top of the transport protocol, so you can choose to use different discovery protocols depending on your transport protocol. These are also configured as sub-elements in the JGroups <literal><config></literal> element."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "PING"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "Here is an example PING configuration for IP multicast."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<PING timeout=\"2000\"\n"
+" num_initial_members=\"3\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Here is another example PING configuration for contacting a Gossip Router."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<PING gossip_host=\"localhost\"\n"
+" gossip_port=\"1234\"\n"
+" timeout=\"2000\" \n"
+" num_initial_members=\"3\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>PING</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">gossip_host</emphasis> specifies the host on which the GossipRouter is running."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">gossip_port</emphasis> specifies the port on which the GossipRouter is listening on."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-separated list of addresses or ports (for example, <literal>host1[12345],host2[23456]</literal>) which are pinged for discovery. Default is <literal>null</literal>, meaning multicast discovery should be used. If <literal>initial_hosts</literal> is specified, you must list all possible cluster members, not just a few well-known hosts, or <literal>MERGE2</literal> cluster split discovery will not work reliably."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "TCPGOSSIP"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<TCPGOSSIP timeout=\"2000\"\n"
+" num_initial_members=\"3\"\n"
+" initial_hosts=\"192.168.5.1[12000],192.168.0.2[12000]\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>TCPGOSSIP</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-separated list of addresses/ports (for example, <literal>host1[12345],host2[23456]</literal>) of <literal>GossipRouter</literal>s to register"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "TCPPING"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The TCPPING protocol takes a set of known members and pings 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
+#, no-c-format
+msgid "<TCPPING timeout=\"2000\"\n"
+" num_initial_members=\"3\"/\n"
+" initial_hosts=\"hosta[2300],hostb[3400],hostc[4500]\"\n"
+" port_range=\"3\">\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>TCPPING</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">initial_hosts</emphasis> is a comma-seperated list of addresses (for example, <literal>host1[12345],host2[23456]</literal>) for pinging."
+msgstr ""
+
+#. Tag: para
+#, 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 <varname>initial_hosts</varname> parameter. Given the current values of <literal>port_range</literal> and <literal>initial_hosts</literal> above, the <literal>TCPPING</literal> layer will try to connect to <literal>hosta[2300]</literal>, <literal>hosta[2301]</literal>, <literal>hosta[2302]</literal>, <literal>hostb[3400]</literal>, <literal>hostb[3401]</literal>, <literal>hostb[3402]</literal>, <literal>hostc[4500]</literal>, <literal>hostc[4501]</literal>, and <literal>hostc[4502]</literal>. This configuration option allows for multiple possible ports on the same host to be pinged without having to spell out all possible combinations. If in your TCP protocol configuration your <literal>end_port</literal> is greater than your <literal>start_port</literal>, we recommend using a TCPPING <litera!
l>port_range</literal> equal to the difference, to ensure a node is pinged no matter which port it is bound to within the allowed range."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "MPING"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>MPING</literal> uses IP multicast to discover the initial membership. Unlike the other discovery protocols, which delegate the sending and receiving of discovery messages on the network to the transport protocol, <literal>MPING</literal> opens its own sockets to send and receive multicast discovery messages. As a result it can be used with all transports, but it is most often used with <literal>TCP</literal>. <literal>TCP</literal> usually requires <literal>TCPPING</literal>, which must explicitly list all possible group members. <literal>MPING</literal> does not have this requirement, and is typically used where <literal>TCP</literal> is required for regular message transport, and UDP multicasting is allowed for discovery."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<MPING timeout=\"2000\"\n"
+" num_initial_members=\"3\"\n"
+" bind_to_all_interfaces=\"true\"\n"
+" mcast_addr=\"228.8.8.8\"\n"
+" mcast_port=\"7500\"\n"
+" ip_ttl=\"8\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>MPING</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface on which to send and receive multicast packets. By default JGroups uses the value of the system property <literal>jgroups.bind_addr</literal>, which can be set with the <code>-b</code> command line switch. See <xref linkend=\"jgroups-other\" /> for more on binding JGroups sockets."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "Failure Detection Protocols"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The failure detection protocols are used to detect failed nodes. Once a failed node is detected, a <emphasis>suspect verification</emphasis> phase can occur. If the node is still considered dead after this phase is complete, the cluster updates its membership view so that further messages are not sent to the failed node. The service using JGroups is informed that the node is no longer part of the cluster. Failure detection protocols are configured as sub-elements in the JGroups <literal><config></literal> element."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "FD"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>FD</literal> is a failure detection protocol based on 'heartbeat' messages. This protocol requires that eat node periodically ping its neighbour. If the neighbour fails to respond, the calling node sends a <literal>SUSPECT</literal> message to the cluster. The current group coordinator can optionally verify that the suspected node is dead (<literal>VERIFY_SUSPECT</literal>). If the node is still considered dead after this verification step, the coordinator updates the cluster's membership view. The following is an example of <literal>FD</literal> configuration:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<FD timeout=\"6000\"\n"
+" max_tries=\"5\"\n"
+" shun=\"true\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>FD</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">shun</emphasis> specifies whether a failed node will be forbidden from sending messages to the group without formally rejoining. A shunned node would need to rejoin the cluster via the discovery process. JGroups allows applications to configure a channel such that, when a channel is shunned, the process of rejoining the cluster and transferring state. (This is default behavior for JBoss Application Server.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Regular traffic from a node is proof of life, so heartbeat messages are only sent when no regular traffic is detected on the node for a long period of time."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "FD_SOCK"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>FD_SOCK</literal> 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, with the final member connecting to the first, forming a ring. Node B becomes suspected when its neighbour, Node A, detects an abnormally closed TCP socket, presumably due to a crash in Node B. (When nodes intend to leave the group, they inform their neighbours so that they do not become suspected.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The simplest <literal>FD_SOCK</literal> configuration does not take any attribute. You can declare an empty <literal>FD_SOCK</literal> element in the JGroups <literal><config></literal> element."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<FD_SOCK/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The attributes available to the <literal>FD_SOCK</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">bind_addr</emphasis> specifies the interface to which the server socket should be bound. By default, JGroups uses the value of the system property <literal>jgroups.bind_addr</literal>. This system property can be set with the <code>-b</code> command line switch. For more information about binding JGroups sockets, see <xref linkend=\"jgroups-other\" />."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "VERIFY_SUSPECT"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid " \n"
+"<VERIFY_SUSPECT timeout=\"1500\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The available attributes in the <literal>VERIFY_SUSPECT</literal> element are listed below."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">timeout</emphasis> specifies how long to wait for a response from the suspected member before considering it dead."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "FD versus FD_SOCK"
+msgstr ""
+
+#. Tag: para
+#, 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: para
+#, no-c-format
+msgid "<emphasis>FD</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "An overloaded machine might be slow in sending are-you-alive responses."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A member will be suspected when suspended in a debugger/profiler."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Low timeouts lead to higher probability of false suspicions and higher network traffic."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "High timeouts will not detect and remove crashed members for some time."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis>FD_SOCK</emphasis>:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Suspended in a debugger is no problem because the TCP connection is still open."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "High load no problem either for the same reason."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Members will only be suspected when TCP connection breaks"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "So hung members will not be detected."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "A failure detection layer is intended to report real failures promptly, while avoiding false suspicions. There are two solutions:"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "<FD_SOCK/>\n"
+"<FD timeout=\"6000\" max_tries=\"5\" shun=\"true\"/>\n"
+"<VERIFY_SUSPECT timeout=\"1500\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In this example, a member becomes suspected when the neighbouring socket has been closed abnormally, in a process crash, for instance, since the operating system closes all sockets. However, if a host or switch crashes, the sockets will not be closed. <literal>FD</literal> will suspect the neighbour after sixty seconds (<literal>6000</literal> milliseconds). Note that if this example system were stopped in a breakpoint in the debugger, the node being debugged will be suspected once the <varname>timeout</varname> has elapsed."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A combination of <literal>FD</literal> and <literal>FD_SOCK</literal> provides a solid failure detection layer, which is why this technique is used across the JGroups configurations included with JBoss Application Server."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Reliable Delivery Protocols"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Reliable delivery protocols within the JGroups stack ensure that messages are actually delivered, and delivered in the correct order (First In, First Out, or FIFO) to the destination node. The basis for reliable message delivery is positive and negative delivery acknowledgments (ACK and NAK). In <literal>ACK</literal> mode, the sender resends the message until acknowledgment is received from the receiver. In <literal>NAK</literal> mode, the receiver requests retransmission when it discovers a gap."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "UNICAST"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>UNICAST</literal> protocol is used for unicast messages. It uses positive acknowlegements (<literal>ACK</literal>). It is configured as a sub-element under the JGroups <literal>config</literal> element. If the JGroups stack is configured with the TCP transport protocol, <literal>UNICAST</literal> 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
+#, no-c-format
+msgid "\n"
+"<UNICAST timeout=\"300,600,1200,2400,3600\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There is only one configurable attribute in the <literal>UNICAST</literal> element."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">timeout</emphasis> specifies the retransmission timeout (in milliseconds). For instance, if the timeout is <literal>100,200,400,800</literal>, the sender resends the message if it has not received an <literal>ACK</literal> after 100 milliseconds the first time, and the second time it waits for 200 milliseconds before resending, and so on. A low value for the first timeout allows for prompt retransmission of dropped messages, but means that messages may be transmitted more than once if they have not actually been lost (that is, the message has been sent, but the <literal>ACK</literal> has not been received before the timeout). High values (<literal>1000,2000,3000</literal>) can improve performance if the network is tuned such that UDP datagram loss is infrequent. High values on networks with frequent losses will be harmful to performance, since later messages will not be delivered until lost messages have been retransmitted."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "NAKACK"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>NAKACK</literal> protocol is used for multicast messages. It uses negative acknowlegements (<literal>NAK</literal>). Under this protocol, each message is tagged with a sequence number. The receiver keeps track of the received sequence numbers and delivers the messages in order. When a gap in the series of received sequence numbers is detected, the receiver schedules a task to periodically ask the sender to retransmit the missing message. The task is cancelled if the missing message is received. <literal>NAKACK</literal> 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
+#, no-c-format
+msgid "\n"
+"<pbcast.NAKACK max_xmit_size=\"60000\" use_mcast_xmit=\"false\" \n"
+" retransmit_timeout=\"300,600,1200,2400,4800\" gc_lag=\"0\"\n"
+" discard_delivered_msgs=\"true\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the <literal>pbcast.NAKACK</literal> element are as follows."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">retransmit_timeout</emphasis> specifies the series of timeouts (in milliseconds) after which retransmission is requested if a missing message has not yet been received."
+msgstr ""
+
+#. Tag: para
+#, 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 to the node requesting it. This is useful when the <emphasis>sender</emphasis>'s network layer tends to drop packets, avoiding the need to individually retransmit to each node."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">max_xmit_size</emphasis> specifies the maximum size (in bytes) for a bundled retransmission, if multiple messages are reported missing."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">discard_delivered_msgs</emphasis> specifies whether to discard delivered messages on the receiver nodes. By default, nodes save delivered messages so any node can retransmit a lost message in case the original sender has crashed or left the group. However, if we only ask the sender to resend its messages, we can enable this option and discard delivered messages."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">gc_lag</emphasis> specifies the number of messages to keep in memory for retransmission, even after the periodic cleanup protocol (see <xref linkend=\"jgroups-other-gc\" />) indicates all peers have received the message. The default value is <literal>20</literal>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Group Membership (GMS)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The group membership service (GMS) protocol 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 any interested services like JBoss Cache or HAPartition, 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
+#, no-c-format
+msgid "\n"
+"<pbcast.GMS print_local_addr=\"true\"\n"
+" join_timeout=\"3000\"\n"
+" join_retry_timeout=\"2000\"\n"
+" shun=\"true\"\n"
+" view_bundling=\"true\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the <literal>pbcast.GMS</literal> element are as follows."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">join_retry_timeout</emphasis> specifies the number of milliseconds to wait after a failed JOIN before trying again."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">print_local_addr</emphasis> specifies whether to dump the node's own address to the standard output when started."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">shun</emphasis> specifies whether a node should shun (that is, disconnect) itself if it receives a cluster view in which it is not a member node."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">disable_initial_coord</emphasis> specifies whether to prevent this node from becoming the cluster coordinator during the initial connection of the channel. This flag does not prevent a node becoming the coordinator after the initial channel connection, if the current coordinator leaves the group."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">view_bundling</emphasis> specifies whether multiple JOIN or LEAVE requests arriving at the same time are bundled and handled together at the same time, resulting in only one new view that incorporates all changes. This is is more efficient than handling each request separately."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Flow Control (FC)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The flow control (FC) protocol tries to adapt the data sending rate to the data receipt rate among nodes. If a sender node is too fast, it might overwhelm the receiver node and result in out-of-memory conditions or dropped packets that have to be retransmitted. In JGroups, 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 send 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 protocol is configured in the <literal>FC</literal> sub-element under the JGroups <literal>config</literal> element. Here is an example configuration."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<FC max_credits=\"2000000\"\n"
+" min_threshold=\"0.10\" \n"
+" ignore_synchronous_response=\"true\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the <literal>FC</literal> element are as follows."
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "<emphasis role=\"bold\">min_credits</emphasis> specifies the minimum number of bytes that must be received before the receiver will send more credits to the sender."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">min_threshold</emphasis> specifies the percentage of the <literal>max_credits</literal> that should be used to calculate <literal>min_credits</literal>. Setting this overrides the <literal>min_credits</literal> attribute."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">ignore_synchronous_response</emphasis> specifies whether threads that have carried messages up to the application should be allowed to carry outgoing messages back down through FC without blocking for credits. <emphasis>Synchronous response</emphasis> refers to the fact that these messages are generally responses to incoming RPC-type messages. Forbidding JGroups threads to carry messages up to block in FC can help prevent certain deadlock scenarios, so we recommend setting this to <literal>true</literal>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Why is FC needed on top of TCP ? TCP has its own flow control!"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "FC is required for group communication where group messages must be sent at the highest speed that the slowest receiver can handle. For example, say we have a cluster comprised of nodes A, B, C and D. D is slow (perhaps overloaded), while the rest are fast. When A sends a group message, it does so via TCP connections: A-A (theoretically), A-B, A-C and A-D."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Say A sends 100 million messages to the cluster. TCP's flow control applies to A-B, A-C and A-D individually, but not to A-BCD as a group. Therefore, A, B and C will receive the 100 million messages, but D will receive only 1 million. (This is also why <literal>NAKACK</literal> is required, even though TCP handles its own retransmission.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JGroups must buffer all messages in memory in case an original sender <emphasis>S</emphasis> dies and a node requests retransmission of a message sent by <emphasis>S</emphasis>. Since all members buffer all messages that they receive, stable messages (messages seen by every node) must sometimes be purged. (The purging process is managed by the <literal>STABLE</literal> protocol. For more information, see <xref linkend=\"jgroups-other-gc\" />.)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the above case, the slow node D will prevent the group from purging messages above 1M, so every member will buffer 99M messages ! This in most cases leads to OOM exceptions. Note that - although the sliding window protocol in TCP will cause writes to block if the window is full - we assume in the above case that this is still much faster for A-B and A-C than for A-D."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "So, in summary, even with TCP we need to FC to ensure we send messages at a rate the slowest receiver (D) can handle."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "So do I always need FC?"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This depends on how the application uses the JGroups channel. Referring to the example above, if there was something about the application that would naturally cause A to slow down its rate of sending because D wasn't keeping up, then FC would not be needed."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A good example of such an application is one that uses JGroups to make synchronous group RPC calls. By synchronous, we mean the thread that makes the call blocks waiting for responses from all the members of the group. In that kind of application, the threads on A that are making calls would block waiting for responses from D, thus naturally slowing the overall rate of calls."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A JBoss Cache cluster configured for REPL_SYNC is a good example of an application that makes synchronous group RPC calls. If a channel is only used for a cache configured for REPL_SYNC, we recommend you remove FC from its protocol stack."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "And, of course, if your cluster only consists of two nodes, including FC in a TCP-based protocol stack is unnecessary. There is no group beyond the single peer-to-peer relationship, and TCP's internal flow control will handle that just fine."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Another case where FC may not be needed is for a channel used by a JBoss Cache configured for buddy replication and a single buddy. Such a channel will in many respects act like a two node cluster, where messages are only exchanged with one other node, the buddy. (There may be other messages related to data gravitation that go to all members, but in a properly engineered buddy replication use case these should be infrequent. But if you remove FC be sure to load test your application.)"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Fragmentation (FRAG2)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This protocol fragments messages that are larger than a certain size, and reassembles them at the receiver's side. It works for both unicast and multicast messages. It is configured with the <literal>FRAG2</literal> sub-element in the JGroups <literal>config</literal> element. Here is an example configuration:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid " \n"
+" <FRAG2 frag_size=\"60000\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the FRAG2 element are as follows."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">frag_size</emphasis> specifies the maximum message size (in bytes) before fragmentation occurs. Messages larger than this size are fragmented. For stacks that use the UDP transport, this value must be lower than 64 kilobytes (the maximum UDP datagram size). For TCP-based stacks, it must be lower than the value of <varname>max_credits</varname> in the FC protocol."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "TCP protocol already provides fragmentation, but a JGroups fragmentation protocol is still required if FC is used. The reason for this is that if you send a message larger than <literal>FC.max_credits</literal>, the FC protocol will block forever. So, <literal>frag_size</literal> within FRAG2 must always be set to a value lower than that of <literal>FC.max_credits</literal>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "State Transfer"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "\n"
+"<pbcast.STATE_TRANSFER/>\n"
+""
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Distributed Garbage Collection (STABLE)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In a JGroups cluster, all nodes must 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. The distributed garbage collection service periodically purges messages that have been seen by all nodes, removing them 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
+#, no-c-format
+msgid "\n"
+"<pbcast.STABLE stability_delay=\"1000\"\n"
+" desired_avg_gossip=\"5000\" \n"
+" max_bytes=\"400000\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the <literal>pbcast.STABLE</literal> element are as follows."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">desired_avg_gossip</emphasis> specifies intervals (in milliseconds) of garbage collection runs. Set this to <literal>0</literal> to disable interval-based garbage collection."
+msgstr ""
+
+#. Tag: para
+#, 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. Set to <literal>0</literal> to disable garbage collection based on the bytes received."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">stability_delay</emphasis> specifies the maximum time period (in milliseconds) of a random delay introduced before a node sends its <literal>STABILITY</literal> message at the end of a garbage collection run. The delay gives other nodes concurrently running a <literal>STABLE</literal> task a chance to send first. If used together with <literal>max_bytes</literal>, this attribute should be set to a small number."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Set the <literal>max_bytes</literal> attribute when you have a high traffic cluster."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Merging (MERGE2)"
+msgstr ""
+
+#. Tag: para
+#, 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 merging 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
+#, no-c-format
+msgid "\n"
+"<MERGE2 max_interval=\"10000\"\n"
+" min_interval=\"2000\"/>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The configurable attributes in the <literal>MERGE2</literal> element are as follows."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">max_interval</emphasis> specifies the maximum number of milliseconds to wait before sending a MERGE message."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<emphasis role=\"bold\">min_interval</emphasis> specifies the minimum number of milliseconds to wait before sending a MERGE message."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JGroups chooses a random value between <literal>min_interval</literal> and <literal>max_interval</literal> to periodically send the MERGE message."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The application state maintained by the application using a channel is not merged by JGroups during a merge. This must be done by the application."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If <literal>MERGE2</literal> is used in conjunction with <literal>TCPPING</literal>, 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 may not detect all sub-groups, and may miss those comprised solely of unlisted members."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Other Configuration Issues"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Binding JGroups Channels to a Particular Interface"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "First, it is important to understand that the value set in any <literal>bind_addr</literal> element in an XML configuration file will be ignored by JGroups if it finds that the system property <literal>jgroups.bind_addr</literal> (or a deprecated earlier name for the same thing, <literal>bind.address</literal>) has been set. The system property has a higher priority level than the XML property. If JBoss Application Server is started with the <literal>-b</literal> (or <literal>--host</literal>) switch, the application server will set <literal>jgroups.bind_addr</literal> to the specified value. If <literal>-b</literal> is not set, the application server will bind most services to <literal>localhost</literal> by default."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "So, what are <emphasis>best practices</emphasis> for managing how JGroups binds to interfaces?"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Binding JGroups to the same interface as other services. Simple, just use <literal>-b</literal>:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -b 192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Binding services (e.g., JBoss Web) to one interface, but use a different one for JGroups:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -b 10.0.0.100 -Djgroups.bind_addr=192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Specifically setting the system property overrides the <literal>-b</literal> value. This is a common usage pattern; put client traffic on one network, with intra-cluster traffic on another."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Binding services (e.g., JBoss Web) to all interfaces. This can be done like this:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -b 0.0.0.0 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "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
+#, no-c-format
+msgid "Binding services (e.g., JBoss Web) to all interfaces, but specify the JGroups interface:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -b 0.0.0.0 -Djgroups.bind_addr=192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Again, specifically setting the system property overrides the <literal>-b</literal> value."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Using different interfaces for different channels:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all"
+msgstr ""
+
+#. Tag: para
+#, 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 various <literal>bind_addr</literal> attributes to the desired interfaces."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Isolating JGroups Channels"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Within JBoss Application Server, there are a number of services that independently create JGroups channels — possibly multiple different JBoss Cache services (used for <literal>HttpSession</literal> replication, EJB3 stateful session bean replication and EJB3 entity replication), two JBoss Messaging channels, and <application>HAPartition</application>, the general purpose clustering service that underlies most other JBossHA services."
+msgstr ""
+
+#. Tag: para
+#, 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 Enterprise Application Platform clustering."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Whom a JGroups channel will communicate with is defined by its group name and, for UDP-based channels, its multicast address and port. Isolating a JGroups channel means ensuring that different channels use different values for the group name, the multicast address and, in some cases, the multicast port."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Isolating sets of Application Server instances from each other"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This section addresses the issue of having multiple independent clusters running within the same environment. For example, you might have a production cluster, a staging cluster, and a QA cluster, or multiple clusters in a QA test lab or development team environment."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To isolate JGroups clusters from other clusters on the network, you must:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Make sure the channels in the various clusters use different group names. This can be controlled with the command line arguments used to start JBoss; see <xref linkend=\"clustering-jgroups-isolation-group-name\" /> for more information."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Make sure the channels in the various clusters use different multicast addresses. This is also easy to control with the command line arguments used to start JBoss."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you are not running on Linux, Windows, Solaris or HP-UX, you may also need to ensure that the channels in each cluster use different multicast ports. This is more difficult than using different group names, although it can still be controlled from the command line. See <xref linkend=\"clustering-jgroups-isolation-mcast_port\" />. Note that using different ports should not be necessary if your servers are running on Linux, Windows, Solaris or HP-UX."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Isolating Channels for Different Services on the Same Set of AS Instances"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This section addresses the usual case: a cluster of three machines, each of which has, for example, an HAPartition deployed alongside JBoss Cache for web session clustering. The HAPartition channels should not communicate with the JBoss Cache channels. Ensuring proper isolation of these channels is straightforward, and is usually handled by the application server without any alterations on the part of the user."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To isolate channels for different services from each other on the same set of application server instances, each channel must have its own group name. The configurations that ship with JBoss Application Server ensure that this is the case. However, if you create a custom service that uses JGroups directly, you must use a unique group name. If you create a custom JBoss Cache configuration, ensure that you provide a unique value in the <literal>clusterName</literal> configuration property."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In releases prior to JBoss Application Server 5, different channels running in the same application server also had to use unique multicast ports. With the JGroups shared transport introduced in JBoss AS 5 (see <xref linkend=\"clustering-blocks-jgroups-sharedtransport\" />), it is now common for multiple channels to use the same tranpsort protocol and its sockets. This makes configuration easier, which is one of the main benefits of the shared transport. However, if you decide to create your own custom JGroups protocol stack configuration, be sure to configure its transport protocols with a multicast port that is different from the ports used in other protocol stacks."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Changing the Group Name"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The group name for a JGroups channel is configured via the service that starts the channel. For all the standard clustered services, we make it easy for you to create unique groups names by simply using the <literal>-g</literal> (or <literal>--partition</literal>) switch when starting JBoss:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -g QAPartition -b 192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This switch sets the <literal>jboss.partition.name</literal> 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: programlisting
+#, no-c-format
+msgid "<property name=\"clusterName\">${jboss.partition.name:DefaultPartition}-SFSBCache</property>"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Changing the multicast address and port"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>-u</literal> (or <literal>--udp</literal>) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services."
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This switch sets the <literal>jboss.partition.udpGroup</literal> system property, which is referenced in all of the standard protocol stack configurations in JBoss AS:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "<UDP mcast_addr=\"${jboss.partition.udpGroup:228.1.2.3}\" ...."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Why is changing the group name insufficient?"
+msgstr ""
+
+#. Tag: para
+#, 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: title
+#, no-c-format
+msgid "Changing the Multicast Port"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On some operating systems (Mac OS X for example), using different <literal>-g</literal> and <literal>-u</literal> values is not sufficient to isolate clusters; the channels running in the different clusters must also use different multicast ports. Unfortunately, setting the multicast ports is not as simple as <literal>-g</literal> and <literal>-u</literal>. By default, a JBoss AS instance running the <literal>all</literal> configuration will use up to two different instances of the JGroups UDP transport protocol, and will therefore open two multicast sockets. You can control the ports those sockets use by using system properties on the command line. For example,"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all \\\\\n"
+" -Djboss.jgroups.udp.mcast_port=12345 -Djboss.messaging.datachanneludpport=23456\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>jboss.messaging.datachanneludpport</literal> property controls the multicast port used by the <literal>MPING</literal> protocol in JBoss Messaging's <literal>DATA</literal> channel. The <literal>jboss.jgroups.udp.mcast_port</literal> property controls the multicast port used by the UDP transport protocol shared by all other clustered services."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The set of JGroups protocol stack configurations included in the <literal>$JBOSS_HOME/server/all/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file includes a number of other example protocol stack configurations that the standard JBoss AS distribution doesn't actually use. Those configurations also use system properties to set any multicast ports. So, if you reconfigure some AS service to use one of those protocol stack configurations, use the appropriate system property to control the port from the command line."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Why do I need to change the multicast port if I change the address?"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "It should be sufficient to just change the address, but unfortunately the handling of multicast sockets is one area where the JVM fails to hide operating system behavior differences from the application. The <literal>java.net.MulticastSocket</literal> class provides different overloaded constructors. On some operating systems, if you use one constructor variant, packets addressed to a particular multicast port are delivered to all listeners on that port, regardless of the multicast address on which they are listening. We refer to this as the <emphasis>promiscuous traffic</emphasis> problem. On most operating systems that exhibit the promiscuous traffic problem (Linux, Solaris and HP-UX) JGroups can use a different constructor variant that avoids the problem. However, on some operating systems with the promiscuous traffic problem (Mac OS X), multicast does not work properly if the other constructor variant is used. So, on these operating systems the recommendation is !
to configure different multicast ports for different clusters."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Improving UDP Performance by Configuring OS UDP Buffer Limits"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "By default, the JGroups channels in JBoss Enterprise Application Platform use the UDP transport protocol to take advantage of IP multicast. However, one disadvantage of UDP is it does not come with the reliable delivery guarantees provided by TCP. The protocols discussed in <xref linkend=\"jgroups-reliable\" /> allow JGroups to guarantee delivery of UDP messages, but those protocols are implemented in Java, not at the operating system network layer. For peak performance from a UDP-based JGroups channel it is important to limit the need for JGroups to retransmit messages by limiting UDP datagram loss."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "One of the most common causes of lost UDP datagrams is an undersized receive buffer on the socket. The UDP protocol's <literal>mcast_recv_buf_size</literal> and <literal>ucast_recv_buf_size</literal> configuration attributes are used to specify the amount of receive buffer JGroups <emphasis>requests</emphasis> from the operating system, but the actual size of the buffer the operating system provides is limited by operating system-level maximums. These maximums are often very low:"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Default Max UDP Buffer Sizes"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Operating System"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Default Max UDP Buffer (in bytes)"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Linux"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "131071"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Windows"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "No known limit"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Solaris"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "262144"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "FreeBSD, Darwin"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "AIX"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "1048576"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The command used to increase the above limits is operating system-specific. The table below shows the command required to increase the maximum buffer to 25 megabytes. In all cases, root privileges are required:"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Commands to Change Max UDP Buffer Sizes"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "Command"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "<literal>sysctl -w net.core.rmem_max=26214400</literal>"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "<literal>ndd -set /dev/udp udp_max_buf 26214400</literal>"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "<literal>sysctl -w kern.ipc.maxsockbuf=26214400</literal>"
+msgstr ""
+
+#. Tag: entry
+#, no-c-format
+msgid "<literal>no -o sb_max=8388608</literal> (AIX will only allow 1 megabyte, 4 megabytes or 8 megabytes)."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "JGroups Troubleshooting"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Nodes do not form a cluster"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, no-c-format
+msgid "java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Then in another window start <literal>McastSenderTest</literal>:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "Causes of missing heartbeats in FD"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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
+#, no-c-format
+msgid "B or C are garbage collecting, same as above."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A combination of the 2 cases above"
+msgstr ""
+
+#. Tag: para
+#, 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
+#, 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/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/FAQ.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/FAQ.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/FAQ.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,79 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Frequently Asked Questions"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "I have problems with Oracle XA?"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>Frequently Asked Questions</primary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Check that you:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You have pad=true for the XidFactory? in conf/jboss-service.xml."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You have <track-connection-by-tx/> in your oracle-xa-ds.xml (not necessarily for JBoss Enterprise Application Platform 5.x where it is enabled by default and the element is deprecated)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You have <isSameRM-override-value>false</isSameRM-override-value> in your oracle-xa-ds.xml."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You have <no-tx-separate-pools/> in your oracle-xa-ds.xml."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "That your jbosscmp-jdbc.xml is specifying the same version of oracle as the one you use."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "That the oracle server you connect to has XA."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Configuring Oracle Database for XA Support You can configure Oracle database to support XA resources. This enables you to use JDBC 2.0-compliant Oracle driver. To XA-initialize Oracle database, complete the following steps:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Make sure that Oracle JServer is installed with your database. If it is not installed, you must add it using Oracle Database Configuration Assistant. Choose \"Change an Existing DB\" and then select the database to which you want to add Oracle JServer. Choose \"Next\", then \"Oracle JServer\" and then \"Finish\". If the settings you have made to your database previously, are not suitable or insufficient for the Oracle JServer installation, the system prompts you to enter additional parameters. The database configuration file ( init.ora ) is located in <literal>\\oracle\\admin\\<your_db_name>\\pfile</literal> directory. Execute initxa.sql over your database. By default, this script file is located in <literal>\\oracle\\ora81\\javavm\\install</literal>. If errors occur during the execution of the file, you must execute the SQL statements from the file manually. Use DBA Studio to create a package and package body named JAVA_XA in SYS schema, and a synonym of this !
package (also named JAVA_XA) in PUBLIC schema."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A slightly more detailed set of instructions can be found at <ulink url=\"http://www.ibm.com/developerworks/websphere/library/techarticles/0407_woolf/0407_woolf.html?ca=dnp-327#oracle_exception\">Configuring and using XA distributed transactions in WebSphere Studio - Oracle Exception section</ulink>."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Feedback.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Feedback.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Feedback.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,65 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Help Contribute"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you find a typographical error in the <citetitle>Administration and Configuration Guide</citetitle>, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in JIRA: <ulink url=\"http://jira.jboss.com\">http://jira.jboss.com</ulink> against the project <citetitle>JBoss Application Server</citetitle> and component <citetitle>Documentation</citetitle>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Be sure to give us your name so you can receive full credit."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This content is taken from svn.jboss.org/repos/jbossas/projects/docs/trunk and has yet to be branched."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To access the content directly and make changes yourself:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "svn co https://svn.jboss.org/repos/jbossas/projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/ --username yourname\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The directory structure includes other languages the book will be translated in. For English please edit the files under <emphasis>en-US</emphasis>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To identify the filename you wish to edit, please check the chapter title which will match the file's name. The files are written in Docbook xml. After saving your changes please validate the files you've edited for errors before committing your changes."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/General_Configuration.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/General_Configuration.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/General_Configuration.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,79 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "General Configuration"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>Configuration</primary><secondary>general</secondary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This chapter covers general configuration issues for the JBoss Enterprise Application Platform."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Hosting multiple domains with your JBoss Enterprise Application Platform"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This section discusses how you can use your application server to host multiple applications for multiple domains."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In this section we use a scenario where a company has three domains with the DNS server pointing to the JBoss Enterprise Application Platform server:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "www.domainA11.net"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "www.domainB12.net"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "www.domainC13.net"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The company has developed three applications to service the above domains which serve its 3 main services:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "applicationA.war"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "applicationB.war"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "applicationC.war"
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/JGroups.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/JGroups.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/JGroups.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,109 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "JGroups"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>JGroups</primary><secondary>multicast communication toolkit</secondary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform clustering is built on JGroups - a toolkit for reliable multicast communication between Enterprise Application Platform nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Group creation and deletion. Group members can be spread across LANs or WANs"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Joining and leaving of groups"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Membership detection and notification about joined/left/crashed members"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Detection and removal of crashed members"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Sending and receiving of member-to-group messages (point-to-multipoint)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Sending and receiving of member-to-member messages (point-to-point)"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Flexible Protocol Stack"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Transport protocols: UDP (IP Multicast), TCP, JMS"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Fragmentation of large messages"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Reliable unicast and multicast message transmission. Lost messages are retransmitted"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Failure detection: crashed members are excluded from the membership"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Membership"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Encryption"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "More information on JGroups can be found on the <ulink url=\"http://www.jboss.org/jgroups/\">The JGroups homepage</ulink>"
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Performance_Tuning.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Performance_Tuning.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Performance_Tuning.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,895 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "JBoss Enterprise Application Platform 5 Performance Tuning"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Introduction"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>JBoss Enterprise Application Platform 5 Performance Tuning</primary><secondary>performance</secondary>"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>Performance</primary><secondary>JBoss Enterprise Application Platform 5 Performance Tuning</secondary>"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>JBoss Enterprise Application Platform</primary><secondary>performance tuning</secondary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Developing applications and deploying them to an Enterprise Application Platform does not guarantee best performance without performance tuning of the applications and server. Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and Enterprise Application Platform."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Application design, hardware/network profile, operating system, application software development, testing and deployment all play a major role in performance tuning. A bottleneck in performance therefore could be caused by these factors not just your application. Recent studies show that most performance problems are the result of the applications not the middleware or the operating systems. This could be associated with the technological developments in computer software, hardware and networking which has increased their reliability."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Improvement of application design and undertaking performance review of your applications before implementation is vital to avoiding bottlenecks after implementation. To undertake a performance review you need to setup a test environment undertake and analyze the test results. To effectively undertake a review, you also need to identify peak application workload times and the difference from normal workload periods. Peak workload times could be during the day, week, certain periods of the month, quarter or year. In understanding peaks workloads it is advisable not to go by averages as the peaks may be much more than the averages calculated over a period. The system requirements are bound by the peaks in the workload not the averages. On undertaking tuning it is recommended to carry out a few more tests and tuning of your system until a satisfactory performance is achieved."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Hardware tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To develop a suitable hardware configuration that suits the performance of your applications on the JBoss Enterprise Application Platform, you need to understand the impact that the selected hardware configuration may have on other applications and overall operating system performance."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To understand hardware performance tuning issues, it is also very critical to understand the hardware architecture of your system."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "CPU (Central Processing Unit)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The CPU is the central processing unit of your computer which consists of:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "a control unit which receives and decides what type of instructions it has received,"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "CPU registers that store intermediate processing information temporarily,"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "a program counter which holds the location of the succeeding executable tasks,"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "instruction register that stores currently executing tasks,"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "CPU cache which is a limited memory that holds data currently being processed by the CPU."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Understanding your CPU architecture can be helpful in identifying your CPU specifications and how it works. For AMD CPU's please refer to <ulink url=\"http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html\">http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html</ulink> for more information. For Intel CPU's please refer to <ulink url=\"http://www.intel.com/products/processor/index.htm?iid=subhdr+prod_proc\">http://www.intel.com/products/processor/index.htm?iid=subhdr+prod_proc</ulink> for more information."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "RAM (Random Access Memory)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Random access memory (RAM) is the next level of storage that can be used to hold executing programs and/or data. RAM chips provides a higher amount of storage than the CPU cache and can improve computer performance. Storing data or programs frequently used in RAM can highly improve performance as they can be retrieved faster than from the hard disk drives."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "RAM is crucial for example when tuning your database management system to manage buffer cache. This would involve storing frequently used database information in RAM for quick application access while taking caution not to affect overall performance of other applications and operating system."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Hard Disk"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Unlike the CPU and RAM, hard disk drives do not require a power source to retain information/data. In case of power loss, information stored in the CPU and RAM is lost while that stored in the hard disk is retained but may be corrupted depending on the type of operation that was in progress during the power loss."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "However retrieval and storage of information from disk drives takes much longer as they use mechanical heads to read and write information to the cylinders of the disk. Storage areas in RAM and in the CPU can be accessed with equal speed while on the hard disk, movement of the disk head to the requested disk block/blocks where information is stored is necessary."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Practices such as disk defragmentation and cleanups can help improve file retrieval and overall performance of your applications. It is therefore crucial to manage the disk storage carefully with the retrieval and processing of data in mind. You also need to identify a suitable file system for your operating system to ensure the best performance possible."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Understanding the main architectural differences and issues that may occur with different computer hardware profiles can help identify a suitable hardware performance and disaster management strategy that would be suitable for your needs."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Operating System Performance Tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Most modern operating systems now ship with performance tuning or profiling tools that can help you monitor CPU, memory, hard disk and network usage in real-time."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "On Windows the task manager and performance monitor can be helpful in identifying system performance bottlenecks while in Unix based operating systems <literal>top</literal> and <literal>ps</literal> are used for the same purpose. Linux distributions such as Red Hat Enterprise Linux and Fedora provide a graphical user interface <literal>System Monitor</literal> that is useful to monitor system performance."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Operating system performance tuning is about resource management to respond to individual requests. Managing operating system scalability on the other hand involves managing resource consumption with varying volumes (low to very high) of requests."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Overall operational performance metrics that are critical for the business such as response time to user requests, database, network, CPU and memory performance among other metrics should be identified and tested and logged in real-time where possible or with system deployments"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For clustered environments, understanding and monitoring your cluster's performance and identifying overloads early is critical to system failure prevention."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Networking"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Network configurations may contribute to performance bottlenecks and may be hard to detect. For example a user may get an error on their browser when trying to load a web application on a dial up connection while the same page may load on a broadband internet connection. The main issue in this scenario may be bandwidth and may not be obviously displayed in the error message displayed."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Identifying network architecture and infrastructure is therefore critical in performance tuning and fixing system bottlenecks."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Most modern operating systems provide you with network hardware configuration tools while some hardware manufacturers may also provide extended network hardware configuration tools with their drivers."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Most operating systems support different communication protocols which you can tweak. Factors such as TCP buffer memory space, connection buffer limits and acknowledgment options among others should be take into account in your network design."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Deciding to turn DNS lookup on or off in your web servers can also affect your performance but may be necessary to turn on for high security environments. Factoring this and allocating necessary resources or hardware can help improve system performance."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Tuning the JVM"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For Java-based applications, it is recommended to also be familiar with tuning of your Java Virtual Machine (JVM). Some key aspects of your JVM that need tweaking include managing out of memory exceptions, Java heap settings and garbage collection. Please refer to the JDK 6 documentation on <ulink url=\"http://java.sun.com/j2se/1.6.0/docs/\">http://java.sun.com/j2se/1.6.0/docs/</ulink> for further discussions on this."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Tuning your applications"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Good application design and development practices are critical to ensuring satisfactory application performance. Data reads or writes and processing by your applications may cause performance bottlenecks due to factors such as timeouts on remote servers memory allocation or network issues among other factors. Understanding how each application works is therefore crucial in identifying performance bottlenecks. Setting expected time duration each code part is expected to take can help develop realistic benchmarks against which the applications can be reviewed. These benchmarks should take into account high and low peak usage times for the applications and not averages as these may highly vary from the peak times."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In addition, using bench`marking tools to test your applications may be a quick way to pinpoint issues in your code which can often be causes for performance bottlenecks. Iterative tests are recommended to identify cache and other hardware issues that may arise due to start up or other factors."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JBoss Enterprise Application Platform web console <ulink url=\"http://localhost:8080/web-console/\">http://localhost:8080/web-console/</ulink> provides you with monitoring tools starting with the JVM environment statistics on the default page and access to monitoring tools and snapshots."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Performance Monitor v/s Profiler"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A performance monitor informs you on overall application performance such as requests per second. Profiling tools such as <ulink url=\"http://www.jboss.org/jbossprofiler/\">JBoss Profiler</ulink> will tell you how long it is taking your application to service a request, and how often it services certain types of requests. This can usually be broken down all the way to the individual methods. For example, how many times a method was called and the average/maximum/minimum amount of time spent in the method."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "It is also important to take caution not to create bottlenecks for other applications while fixing a performance issue in one application."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Instrumentation"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Applications should be instrumented for performance analysis. In most cases, the actual production workload is different than the expected workload. Without instrumentation of your applications, you will lack accurate tracking data. Workloads on your applications can also change over time, as the business size, models or environment changes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Instrumentation in the past would have had to be embedded in the application. Today, there are many solutions for instrumentation that do not require developers to code. Commercial products, and the JBoss AOP framework can be used for just this purpose. You can also turn on call statistics in the containers, and Hibernate statistics. For more on this please refer to the AOP and Hibernate project pages."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Taking successive thread dumps (includes the current call stack for each Java Enterprise Application Platform thread) can give the application developers enough information to get a sense for what is going on in the application. This is something that you might do after the application has hit a performance wall. If the performance problem lasts for five minutes, you might generate a thread dump one a minute. You can use the JVM \"jps -l\" command to get a list of running Java applications and the process ids for each. Note the process ID for the \"org.jboss.Main\" application. You will then run the \"jstack ProcessID\" command (replacing ProcessID with the \"org.jboss.Main\" process ID) and that will generate the thread dump. Of course, you should redirect the output of the jstack command to save the output (\"jstack ProcessID > threaddump1.txt\")."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Tuning JBoss Enterprise Application Platform"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Before tuning the JBoss Enterprise Application Platform, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the server. This section discusses these among other JBoss Enterprise Application Platform performance tuning topics."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Memory usage"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Memory usage of Java applications including the JBoss Enterprise Application Platform is dictated by the heap space allocated. You could therefore as an example, reduce 1GB heap space you currently have allocated to 800MB to reduce memory footprint (if you have enough headroom)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The Java Virtual Machine (JVM) manages segments (generations) of memory. If a segment of the heap space is exhausted, you will see a Java OutOfMemoryError (OOME). All bets are off, when you get a Java OutOfMemoryError. The application should be restarted to correct any bad state. Part of tuning is checking how much memory headroom you have while under load. If available memory is too low, you will need to increase the max Java memory size (possibly switching to a 64-bit JVM if needed)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Running out of memory generates an Error that is not likely to be masked in a Java catch block because it is an Error rather than an Exception. An OOME is also thrown when the permanent memory is exhausted and that is not part of the heap. That is a JVM specific area of memory where information on loaded classes is maintained. If you have a mountain of classes (e.g, a lot of EJBs and JSP pages) you can easily exhaust this area. Oftentimes an application will fail to deploy or fail to redeploy. Increase your permanent memory space as follows to avoid OOMEs. The default with the <literal>-server</literal> switch is 64 megabytes:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "-XX:MaxPermSize=256m"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Note this is in addition to the heap. In this case we have 512M heap, 256M permanent space for a total of 768 megabytes. Don't forget the JVM itself takes up a chunk of system memory and there is also per thread stack space (size varies based on OS). That can add up with a lot of HTTP/S processors."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<literal>-XX:MaxPermSize=256m -Xmx512m</literal> (total of 768 megabytes allocated from system - this is not the total size of the VM and does not include the space the VM allocates for the \"C heap\" or stack space)"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The HotSpot Java Virtual Machine consists of various garbage collection tools which you can use to collect garbage collection information that you can use to tune your applications. You can find more information on the HotSpot Virtual machine on <ulink url=\"http://java.sun.com/javase/technologies/hotspot/\">http://java.sun.com/javase/technologies/hotspot/</ulink>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Java 6 includes new tools that help monitor Java applications. Jmap can generate a heap dump file (<ulink url=\"http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html\">http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html</ulink>) that can easily be read by the Eclipse Memory Analyzer tool (<ulink url=\"http://www.eclipse.org/mat/\">http://www.eclipse.org/mat/</ulink>). The jstat tool (<ulink url=\"http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html\">http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html</ulink>) can help give you a precise picture of your permanent memory space and the other segments on the Java memory heap."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "VFS Tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "When looking for various tuning options for the VFS (Virtual File System), most of the information that exists can be found in <classname>VFSUtils</classname> class. Its string constants point us to different possible system property settings we can use to configure VFS behavior:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<property>jboss.vfs.forceCopy</property>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This defines how nested jars should be handled. If forceCopy is true (the default), we create a temporary copy of the nested jar, and re-wire VFS accordingly. If forceCopy is false, we handle nested jars in-memory, which doesn't create temporary copy, but is more memory consuming."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<property>jboss.vfs.forceVfsJar</property> has the options true and false, with the default being false."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "By setting this property to true, you can implement the old JAR handling. Set to false by default, old JAR handling was deprecated in favor of new ZIP handling code."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<property>jboss.vfs.forceNoReaper</property> has the options true and false, with the default being false."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "To gain a bit on performance, we close JAR files asynchronously via the separate reaper thread. If you wish to close JAR files synchronously, you can force no usage of the reaper thread. This can also be defined using the URI query and the <literal>noReaper</literal> query section."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<property>jboss.vfs.forceCaseSensitive</property> has the options true and false, with the default being false."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "With this enabled you can force differentiation between lower and upper cased file paths."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<property>jboss.vfs.optimizeForMemory</property> has the options true and false, with the default being false."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "With this enabled we re-order in-memory JAR handling, to gain on memory consumption."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <classname>jboss.vfs.cache</classname> (<classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname>) class can be defined in order to re-use existing temporary files (in order not to re-do all unpacking and wiring). The VFS registry will use the defining of this class to keep its existing VFS roots."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Every <methodname>VirtualFile</methodname> lookup from the VFS class uses this <literal>singleton</literal> cache instance to check for an existing matching cache entry. By matching we also consider any existing <emphasis>ancestor</emphasis> from which you can use exact <methodname>VirtualFile</methodname> instance."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "VFS Cache Tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "As described before, VFS cache holds VFS roots, from which any VirtualFile lookup can access existing VirtualFile instances. This is a sepcially useful in the case of temporary files (created from nested JARs), meaning you don't have to do multiple unpackings for nested JAR file related resources."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "By default in VFS there is no caching involved as <classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname> is used. But you can provide your own implementation or choose from existing VFS implementations."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Cache implementations from the <literal>org.jboss.virtual.plugins.cache</literal> package are:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<classname>SoftRefVFSCache</classname>: uses soft reference as map's entry value."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<classname>WeakRefVFSCache</classname>: uses weak reference as map's entry value."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<classname>TimedVFSCache</classname>: evicts cache entries after defaultLifetime."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<classname>LRUVFSCache</classname>: evicts cache entries based on LRU, keeping min and max entries."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<classname>CombinedVFSCache</classname>: holds few permanent roots, any other new root is cached in its realCache property."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the JBoss Enterprise Application Platform we use <classname>CombinedVFSCache</classname> as we know which are our permanent roots to watch and keep. This is how it's configured in MC's bean configuration file."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" <bean name=\"VFSCache\">\n"
+" <constructor factoryClass=\"org.jboss.virtual.spi.cache.VFSCacheFactory\" factoryMethod=\"getInstance\">\n"
+" <!-- Use the CombinedVFSCache implementation -->\n"
+" <parameter>org.jboss.virtual.plugins.cache.CombinedVFSCache</parameter>\n"
+" </constructor>\n"
+" <start ignored=\"true\"/>\n"
+" <property name=\"permanentRoots\">\n"
+" <map keyClass=\"java.net.URL\" valueClass=\"org.jboss.virtual.spi.ExceptionHandler\">\n"
+" <entry>\n"
+" <key>${jboss.lib.url}</key>\n"
+" <value><null/></value>\n"
+" </entry>\n"
+" <entry>\n"
+" <key>${jboss.common.lib.url}</key>\n"
+" <value><inject bean=\"VfsNamesExceptionHandler\"/></value>\n"
+" </entry>\n"
+" <entry>\n"
+" <key>${jboss.server.lib.url}</key>\n"
+" <value><inject bean=\"VfsNamesExceptionHandler\"/></value>\n"
+" </entry>\n"
+" <entry>\n"
+" <key>${jboss.server.home.url}deploy</key>\n"
+" <value><inject bean=\"VfsNamesExceptionHandler\"/></value>\n"
+" </entry>\n"
+" </map>\n"
+" </property>\n"
+" <property name=\"realCache\">\n"
+" <bean class=\"org.jboss.virtual.plugins.cache.IterableTimedVFSCache\"/>\n"
+" </property>\n"
+" </bean>\n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Any new custom VFS root (for example, an additional <filename>deploy</filename> directory) should be added to this configuration."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Annotation Scanning Tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There are currently three ways to limit resources scanning."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Provide a <classname>ScanningMetaData</classname> through XML or programmaticaly."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Add a new deployment filter to <classname>GenScanDeployer</classname> bean in <filename>deployers/metadata-deployer-jboss-beans</filename>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Modify <classname>JBossCustomDeployDUFilter</classname> in <filename>deployers/metadata-deployer-jboss-beans</filename>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "ScanningMetaData can come from the <filename>jboss-scanning.xml</filename> file placed in <filename>META-INF</filename> directory. This is a simple example of this file:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<scanning xmlns=\"urn:jboss:scanning:1.0\">\n"
+" <path name=\"myejbs.jar\">\n"
+" <include name=\"com.acme.foo\"/>\n"
+" <exclude name=\"com.acme.foo.bar\"/>\n"
+" </path>\n"
+" <path name=\"my.war/WEB-INF/classes\">\n"
+" <include name=\"com.acme.foo\"/>\n"
+" </path>\n"
+"</scanning> \n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Here you list the paths inside your deployment, and which packages to include or exclude. If there is no explicit include, everything that is not excluded is included. If there is no path element at all, everything is excluded, as in the following example."
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+"<scanning xmlns=\"urn:jboss:scanning:1.0\">\n"
+"<!-- Purpose: Disable scanning for annotations in contained deployment. -->\n"
+"</scanning> \n"
+""
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Another way to limit scanning is to provide the <filename>jboss-classloading.xml</filename> file. More information about this can be found in the Class Loader documentation section as it covers a lot of other details as well, not just scanning."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Database Connection"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Database performance tuning involves changing the initial database conceptual schema to improve performance. Irrespective of type, overall database management system performance tuning involves effective and efficient use of your hardware (hard disk, CPU and RAM) and improving database reads and writes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Resource limits set by your operating system may also set limits on your database management system. A database administrator can analyze a database and identify performance bottlenecks through taking the above factors into consideration and adjusting the necessary database management system parameters such as writing dirty buffers to disk, checkpoints and log file rotations. In some instances hardware upgrades may also be necessary to improve database performance."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss Enterprise Application Platform by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss Enterprise Application Platform and utilizing the connection pool settings. Connection pooling in the JBoss Enterprise Application Platform allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Depending on the databases implemented, please ensure you create a data source file in the deploy directory of your configuration as shown below:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "<JBoss_Home>/server/<your_configuration>/deploy/"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The filename should be in the following formats:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "<yourdatabasename>-ds.xml"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss Enterprise Application Platform to recognize it as a <emphasis>data source file</emphasis>. The PostgreSQL database data source file for example is named <filename>postgres-ds.xml</filename>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Examples"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Examples of datasource definition files for external databases can be found in the <literal><JBoss_Home>/docs/examples/jca</literal> directory."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Clustering Tuning"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you are running your application in a cluster, particularly if it involves high volume state replication around the cluster, there are a number of possible performance optimizations. As with any performance optimizations, always load test your application before and after making changes to verify the change has the intended effect, and make one change at a time so it's clear what change has what effect."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Ensuring Adequate Network Buffers"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The standard clustered services in the Enterprise Application Platform use UDP for intra-cluster communication, in order to take advantage of UDP-based IP multicast. A downside to the use of UDP is some of the lossless transmission guarantees that are provided at the OS network level with TCP instead need to be implemented in Java code. In order to achieve peak performance it is important to reduce the frequency of UDP packets being dropped in the network layers. A frequent cause of lost packets is inadequately sized network buffers on the machines that are hosting the cluster nodes. The Enterprise Application Platform clustering code will <emphasis>request</emphasis> adequately sized read and write buffers from the OS when it opens sockets, but most operating systems (Windows seems to be an exception) will only <emphasis>provide</emphasis> buffers up to a maximum size. This maximum read and write buffer sizes are configurable at the OS level, and the default values !
are too low to allow peak performance. So, a simple tuning step is to configure your OS to allow buffers up to the size the Enterprise Application Platform clustering code will request."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The specific configuration steps needed to increase the maximum allowed buffer sizes are OS specific. See your OS documentation for instructions on how to increase these. For Linux systems, maximum values for these buffers sizes that will survive machine restarts can be set by editing the <literal>/etc/sysctl.conf</literal> file:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "# Allow a 25MB UDP receive buffer for JGroups\n"
+"net.core.rmem_max = 26214400\n"
+"# Allow a 1MB UDP send buffer for JGroups\n"
+"net.core.wmem_max = 1048576"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Isolating Intra-Cluster Traffic"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If network resources are a bottleneck for your application, overall performance can be improved by isolating intra-cluster traffic from external request traffic. This requires multiple NICs on your server machines, with request traffic coming in on one NIC and intra-cluster traffic using another. Once you have the hardware set up, it is easy to tell the Enterprise Application Platform nodes to use a different interface for the intra-cluster traffic:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "./run.sh -c all -b 10.0.0.104 -Djgroups.bind_addr=192.168.100.104"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the above example, the <literal>-Djgroups.bind_addr</literal> setting tells the the Enterprise Application Platform to run intra-cluster JGroups traffic over the 192.168.100.104 interface, with <literal>-b</literal> specifying that all other traffic should use 10.0.0.104."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "JGroups Message Bundling"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JGroups group communication library used by the Enterprise Application Platform provides a feature known as \"message bundling\". Message bundling is similar to nagling on a TCP socket — small messages are queued before sending (for up to a configurable maximum time) until a configurable number of bytes have accumulated, and then the queued messages are bundled and sent as one large message. Use of bundling can have significant performance benefits for high-volume asynchronous session replication. However, it is not enabled by default, as bundling can add significant latency to other types of intra-cluster traffic, particularly clustered Hibernate/JPA Second Level Cache traffic."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your application uses high volume session replication (web sessions or EJB3 stateful session beans), you might be able to increase performance by configuring the distributed caching layer to use a JGroups channel configured with message bundling enabled. This is done by editing the <literal><JBoss_Home>/server/<your_configuration>/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-jboss-beans.xml</literal> file. For example, for the cache used by default for web sessions:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid ". . .\n"
+" \n"
+"<!-- Standard cache used for web sessions -->\n"
+"<entry><key>standard-session-cache</key>\n"
+"<value> \n"
+" <bean name=\"StandardSessionCacheConfig\" class=\"org.jboss.cache.config.Configuration\">\n"
+" \n"
+" . . . \n"
+" \n"
+" <!-- Replace standard 'udp' JGroups stack with \n"
+" one that uses message bundling -->\n"
+" <property name=\"multiplexerStack\">udp-async</property>\n"
+" \n"
+" . . ."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For FIELD granularity web sessions, in the same file the same change can be made to the cache configuration with the <literal>field-granularity-session-cache</literal> key. For EJB3 stateful session beans, in the same file the same change can be made to the cache configuration with the <literal>sfsb-cache</literal> key."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Using the <literal>udp-async</literal> JGroups protocol stack for the session caches means an additional JGroups transport protocol will be used. This means additional sockets will be opened compared to a standard Enterprise Application Platform installation."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Enabling Buddy Replication for Session Caches"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your application involves high volume replication of web sessions or EJB3 stateful session beans in a cluster of more than two nodes, you can improve performance by enabling \"buddy replication\" in the web session and stateful session bean caches. With buddy replication, instead of replicating a copy of sessions to all nodes in the cluster, a copy is only replicated to a configurable number of \"buddy\" nodes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Buddy replication is enabled done by editing the <literal><JBoss_Home>/server/<your_configuration>/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-jboss-beans.xml</literal> file. For example, for the cache used by default for web sessions:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid ". . .\n"
+" \n"
+"<!-- Standard cache used for web sessions -->\n"
+"<entry><key>standard-session-cache</key>\n"
+"<value> \n"
+" <bean name=\"StandardSessionCacheConfig\" class=\"org.jboss.cache.config.Configuration\">\n"
+" \n"
+" . . . \n"
+" \n"
+" <property name=\"buddyReplicationConfig\">\n"
+" <bean class=\"org.jboss.cache.config.BuddyReplicationConfig\">\n"
+" \n"
+" <!-- Just set to true to turn on buddy replication -->\n"
+" <property name=\"enabled\">true</property>\n"
+" \n"
+" . . ."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Reducing the Volume of Web Session Replication"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your application is configured for web session replication, reducing the amount data being replicated can obviously improve performance. This can be accomplished both by avoiding replication when a request hasn't actually updated the session and by limiting replication to only the session data that has actually changed. See the discussion of <emphasis role=\"bold\">replication-trigger</emphasis> and <emphasis role=\"bold\">replication-granularity</emphasis> in <xref linkend=\"clustering-http-state\" /> for how to configure your application to limit the amount of data replicated."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Reducing the Volume of EJB3 Stateful Session Bean Replication"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If your application is configured for EJB3 Stateful Session Bean replication, avoiding replication after bean requests that haven't modified state can improve performance. This can be controlled by having your bean class implement the <literal>org.jboss.ejb3.cache.Optimized</literal> interface. See <xref linkend=\"clustering-session-sfsb30\" /> for details."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Be Cautious with JPA/Hibernate Second Level Caching"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JPA and Hibernate applications can often gain a performance boost by caching database data in the application server. However, with a clustered application the decision of whether or not to cache data is more complex than in the non-clustered case. This is because in a cluster, when database writes occur on one node, the caching layer needs to send a message to all other nodes in the cluster telling them to update or invalidate their cache content. For types of data that are frequently updated, the cost of the intra-cluster messages can outweigh the benefits of caching."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "So, be sure to carefully load test your clustered application when deciding whether to store items in the Hibernate Second Level Cache. Avoid the temptation to turn on caching for all entity types; instead rank your entity types based on how infrequent writes of each type are and how likely it is that more than one transaction will read a particular entity. Then enable caching for one type at a time, testing for the performance impact."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Be doubly cautious about enabling caching of query result sets. When query caching is enabled, any time there is a database write, the clustered cache needs to send <emphasis>two</emphasis> messages around the cluster. These messages are used to ensure that any query results that may have been affected by the write are invalidated out of the cache. These messages need to be sent whether or not the entity type that has been written is itself cached. The cost of these messages can easily offset the benefit of query result caching. So, again, be sure to test the effect of caching."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Monitoring JGroups via JMX"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "When the Enterprise Application Platform clustering services create a JGroups <literal>Channel</literal> to use for intra-cluster communication, they also register with the JMX server a number of MBeans related to that channel; one for the channel itself and one for each of its constituent protocols. For users interested in monitoring the performance-related behavior of a channel, a number of MBean attributes may prove useful."
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<emphasis role=\"bold\">jboss.jgroups:cluster=<cluster_name>,protocol=UDP,type=protocol</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Provides statistical information on the sending and receipt of messages over the network, along with statistics on the behavior of the two thread pools used to carry incoming messages up the channel's protocol stack."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Useful attributes directly related to the rate of transmission and receipt include <literal>MessagesSent</literal>, <literal>BytesSent</literal>, <literal>MessagesReceived</literal> and <literal>BytesReceived</literal>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Useful attributes related to the behavior of the thread pool used to carry ordinary incoming messages up the protocol stack include <literal>IncomingPoolSize</literal> and <literal>IncomingQueueSize</literal>. Equivalent attributes for the pool of threads used to carry special, unordered \"out-of-band\" messages up the protocol stack include <literal>OOBPoolSize</literal> and <literal>OOBQueueSize</literal>. Note that <literal>OOBQueueSize</literal> will typically be <literal>0</literal> as the standard JGroups configurations do not use a queue for OOB messages."
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<emphasis role=\"bold\">jboss.jgroups:cluster=<cluster_name>,protocol=UNICAST,type=protocol</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Provides statistical information on the behavior of the protocol responsible for ensuring lossless, ordered delivery of unicast (i.e. point-to-point) messages."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The ratio of <literal>NumRetransmissions</literal> to <literal>MessagesSent</literal> can be tracked to see how frequently messages are not being received by peers and need to be retransmitted. The <literal>NumberOfMessagesInReceiveWindows</literal> attribute can be monitored to track how many messages are queueing up on a receipient node waiting for a message with an earlier sequence number to be received. A high number indicates messages are being dropped and need to be retransmitted."
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<emphasis role=\"bold\">jboss.jgroups:cluster=<cluster_name>,protocol=NAKACK,type=protocol</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Provides statistical information on the behavior of the protocol responsible for ensuring lossless, ordered delivery of multicast (i.e. point-to-multipoint) messages."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Use the <literal>XmitRequestsReceived</literal> attribute to track how often a node is being asked to retransmit a messages it sent; use <literal>XmitRequestsSent</literal> to track how often a node is needing to request retransmission of a message."
+msgstr ""
+
+#. Tag: term
+#, no-c-format
+msgid "<emphasis role=\"bold\">jboss.jgroups:cluster=<cluster_name>,protocol=FC,type=protocol</emphasis>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Provides statistical information on the behavior of the protocol responsible for ensuring fast message senders do not overwhelm slow receivers."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Attributes useful for monitoring whether threads seeking to send messages are having to block while waiting for credits from receivers include <literal>Blockings</literal>, <literal>AverageTimeBlocked</literal> and <literal>TotalTimeBlocked</literal>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Other key configurations"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Other key configurations required for performance tuning of your Enterprise Application Platform include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "JBoss Enterprise Application Platform 5 has a robust thread pooling, that should be sized appropriately. The server has a <filename>jboss-service.xml</filename> file in the <filename><JBoss_Home>/server/<your_configuration>/conf</filename> directory that defines the system thread pool. There is a setting that defines the behavior if there isn't a thread available in the pool for execution. The default is to allow the calling thread to execute the task. You can monitor the queue depth of the system thread pool through the JMX Console, and determine from that if you need to make the pool larger."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The new administration console can be used for configuring and managing different aspects of the Enterprise Application Platform environment."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The <literal>default</literal> configuration is appropriate for development, but not necessarily for a production environment. In the default configuration, console logging is enabled. Console logging is ideal for development, especially within the IDE, as you get all the log messages to show in the IDE console view. In a production environment, console logging is very expensive and is not recommended. Turn down the verbosity level of logging if its not necessary. Please note that the less you log, the less I/O will be generated, and the better the overall throughput will be."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Other performance tuning aspects include Caching, Clustering and Replication which are discussed in the respective Chapters in this book."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Pooling.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Pooling.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Pooling.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,361 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Pooling"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Strategy"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>Pooling</primary><secondary>JBossJCA</secondary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<ulink url=\"http://www.jboss.org/community/wiki/JBossJCA\">JBossJCA</ulink> uses a <literal>ManagedConnectionPool</literal> to perform the pooling. The <literal>ManagedConnectionPool</literal> is made up of subpools depending upon the strategy chosen and other pooling parameters."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "xml"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "mbean"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Internal Name"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Description"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid " "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "ByNothing"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "OnePool"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A single pool of equivalent connections"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<application-managed-security/>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "ByApplication"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "PoolByCRI"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Use the connection properties from allocateConnection()"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<security-domain/>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "ByContainer"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "PoolBySubject"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A pool per Subject, e.g. preconfigured or EJB/Web login subjects"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<security-domain-and-applicaton/>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "ByContainerAndApplicaton"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "PoolBySubjectAndCri"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A per Subject and connection property combination"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Note"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The xml names imply this is just about security. This is misleading."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For <security-domain-and-application/> the Subject always overrides any user/password from createConnection(user, password) in the CRI:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "(\n"
+"ConnectionRequestInfo\n"
+") "
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Transaction stickness"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You can force the same connection from a (sub-)pool to get reused throughout a transaction with the <track-connection-by-tx/> flag"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This is the only supported behaviour for <emphasis>\"local\"</emphasis> transactions. This element is deprecated in JBoss Enterprise Application Platform 5 where transaction stickiness is enabled by default. XA users can explicitly enable interleaving with <interleaving/> element."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Workaround for Oracle"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Oracle does not like XA connections getting used both inside and outside a JTA transaction. To workaround the problem you can create separate sub-pools for the different contexts using <no-tx-separate-pools/>."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Pool Access"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The pool is designed for concurrent usage."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Upto <max-pool-size/> threads can be inside the pool at the same time (or using connections from a pool)."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Once this limit is reached, threads wait for the <blocking-timeout-seconds/> to use the pool before throwing a <ulink url=\"http://www.jboss.org/community/wiki/WhatDoesTheMessageNoManagedConnectionsAvailableMean\">No Managed Connections Available</ulink>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You may want to use the <allocation-retry/> and <allocation-retry-wait-millis/> elements to have the pool retry to obtain a connection before throwing the exception."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Pool Filling"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The number of connections in the pool is controlled by the pool sizes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<min-pool-size/> - When the number of connections falls below this size, new connections are created"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<max-pool-size/> - No more than this number of connections are created"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<prefill/> - Feature Request has been implemented for 4.0.5. Note: the only pooling strategy that supports this feature is OnePool?, or ByNothing? pooling criteria."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The pool filling is done by a separate \"Pool Filler\" thread rather than blocking application threads."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Idle Connections"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You can configure connections to be closed when they are idle. e.g. If you just had a peak period and now want to reap the unused ones. This is done via the <idle-timeout-minutes/>."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Idle checking is done on a separate \"Idle Remover\" thread on an LRU (least recently used) basis. The check is done every idle-timeout-minutes divided by 2 for connections unused for idle-timeout-minutes."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The pool itself operates on an MRU (most recently used) basis. This allows the excess connections to be easily identified."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Should closing idle connections cause the pool to fall below the min-pool-size, new/fresh connections are created."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "If you have long running transactions and you use interleaving (i.e. don't track-connection-by-tx) make sure the idle timeout is greater than the transaction timeout. When interleaving the connection is returned to the pool for others to use. If however nobody does use it, it would be a candidate for removal before the transaction is committed."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Dead connections"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The JDBC protocol does not provide a natural <literal>connectionErrorOccured()</literal> event when a connection is broken. To support dead/broken connection checking there are a number of plugins."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Valid connection checking"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The simplest format is to just run a \"quick\" sql statement:"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "before handing the connection to the application. If this fails, another connection is selected until there are no more connections at which point new connections are constructed."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The potentially more performant check is to use vendor specific features, e.g. Oracle's or MySQL's pingDatabase() via the"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "<valid-connection-checker-class-name/>"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Errors during SQL queries"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "You can check if a connection broke during a query by the looking the error codes or messages of the SQLException for FATAL errors rather than normal SQLExceptions. These codes/messages can be vendor specific, e.g."
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "For"
+msgstr ""
+
+#. Tag: screen
+#, no-c-format
+msgid "FATAL"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "errors the connection will be closed."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Changing/Closing/Flushing the pool"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<ulink url=\"http://www.jboss.org/community/wiki/HowDoIChangeThePoolingParameters\">change or flush()</ulink> the pool"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "closing/undeploying the pool will do a flush first"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Other pooling"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "<ulink url=\"http://www.jboss.org/community/docs/DOC-10020?uniqueTitle=false\">Thirdparty Pools</ulink> - only if you know what you are doing"
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Remoting.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Remoting.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Remoting.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,332 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:27\n"
+"PO-Revision-Date: 2010-05-27T07:30:27\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Remoting"
+msgstr ""
+
+#. Tag: indexterm
+#, no-c-format
+msgid "<primary>Remoting</primary><secondary>about</secondary>"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The main objective of JBoss Remoting is to provide a single API for most network based invocations and related services that use pluggable transports and data marshallers. The JBoss Remoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the addition of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes, to fit these different needs."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Out of the box, Remoting supplies multiple transports (bisocket, http, rmi, socket, servlet, and their ssl enabled counterparts), standard and compressing data marshallers, and a configurable facility for switching between standard jdk serialization and JBoss Serializabion. It is also capable of remote classloading, has extensive facilities for connection failure notification, performs call by reference optimization for client/server invocations collocated in a single JVM, and implements multihomed servers."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the Enterprise Application Platform, Remoting supplies the transport layer for the EJB2, EJB3, and Messaging subsystems. In each case, the configuration of Remoting is largely predetermined and fixed, but there are times when it is useful to know how to alter a Remoting configuration."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Background"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "A Remoting server consists of a Connector, which wraps and configures a transport specific server invoker. A connector is represented by an InvokerLocator string, such as"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" socket://bluemonkeydiamond.com:8888/?timeout=10000&serialization=jboss\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "which indicates that a server using the socket transport is accessible at port 8888 of host bluemonkeydiamond.com, and that the server is configured to use a socket timeout of 10000 and to use JBoss Serialization. A Remoting client can use an InvokerLocator to connect to a given server."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the Enterprise Application Platform, Remoting servers and clients are created far below the surface and are accessible only through configuration files. Moreover, when a SLSB, for example, is downloaded from the JNDI directory, it comes with a copy of the InvokerLocator, so that it knows how to contact the appropriate Remoting server. <emphasis role=\"bold\">The important fact to note is that, since the server and its clients share the InvokerLocator, the parameters in the InvokerLocator serve to configure both clients and servers.</emphasis>"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "JBoss Remoting Configuration"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "There are two kinds of XML files that can be used to create and configure a Remoting Connector. A file with a name of the form *-service.xml can be used to define a Connector as an MBean, and a file of the form *-jboss-beans.xml can be used to define a Connector as a POJO."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "MBeans"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In the HornetQ JMS subsystem, a Remoting server is configured in the file remoting-bisocket-service.xml, which, in abbreviated form, looks like"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" <mbean code=\"org.jboss.remoting.transport.Connector\"\n"
+" name=\"jboss.messaging:service=Connector,transport=bisocket\"\n"
+" display-name=\"Bisocket Transport Connector\">\n"
+" <attribute name=\"Configuration\">\n"
+" <config>\n"
+" <invoker transport=\"bisocket\"> \n"
+" <attribute name=\"marshaller\" isParam=\"true\">org.jboss.jms.wireformat.JMSWireFormat</attribute>\n"
+" <attribute name=\"unmarshaller\" isParam=\"true\">org.jboss.jms.wireformat.JMSWireFormat</attribute> \n"
+" <attribute name=\"serverBindAddress\">${jboss.bind.address}</attribute>\n"
+" <attribute name=\"serverBindPort\">4457</attribute>\n"
+" <attribute name=\"callbackTimeout\">10000</attribute>\n"
+" ... \n"
+" </invoker>\n"
+" ...\n"
+" </config>\n"
+" </attribute>\n"
+" </mbean>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This configuration file tells us several facts, including"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "This server uses the bisocket transport;"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "it runs on port 4457 of host ${jboss.bind.address}; and"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "HornetQ uses its own marshalling algorithm."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The InvokerLocator is derived from this file. <emphasis role=\"bold\">The important fact to note is that the attribute \"isParam\" determines if a parameter is to be included in the InvokerLocator.</emphasis> If \"isParam\" is omitted or set to false, the parameter will apply only to the server. In this case, the parameter will not be transmitted to the client. The InvokerLocator for a Remoting server with a ${jboss.bind.address} of bluemonkeydiamond.com would be:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" bisocket://bluemonkeydiamond.com:4457/?marshaller=\n"
+" org.jboss.jms.wireformat.JMSWireFormat&\n"
+" unmarshaller=org.jboss.jms.wireformat.JMSWireFormat\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Note that the parameter \"callbackTimeout\" is not included in the InvokerLocator."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "POJOs"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The same Connector could be configured by way of the <classname>org.jboss.remoting.ServerConfiguration</classname> POJO:"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" <bean name=\"HornetQConnector\" class=\"org.jboss.remoting.transport.Connector\">\n"
+" <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX\n"
+" (name=\"jboss.messaging:service=Connector,transport=bisocket\",\n"
+" exposedInterface=org.jboss.remoting.transport.ConnectorMBean.class,\n"
+" registerDirectly=true)</annotation>\n"
+" <property name=\"serverConfiguration\"><inject bean=\"HornetQConfiguration\"/></property>\n"
+" </bean>\n"
+" \n"
+" <!-- Remoting server configuration -->\n"
+" <bean name=\"HornetQConfiguration\" class=\"org.jboss.remoting.ServerConfiguration\">\n"
+" <constructor>\n"
+" <parameter>bisocket</parameter>\n"
+" </constructor>\n"
+" \n"
+" <!-- Parameters visible to both client and server -->\n"
+" <property name=\"invokerLocatorParameters\">\n"
+" <map keyClass=\"java.lang.String\" valueClass=\"java.lang.String\">\n"
+" <entry>\n"
+" <key>serverBindAddress</key>\n"
+" <value>\n"
+" <value-factory bean=\"ServiceBindingManager\" method=\"getStringBinding\">\n"
+" <parameter>HornetQConnector</parameter>\n"
+" <parameter>${host}</parameter>\n"
+" </value-factory>\n"
+" </value>\n"
+" </entry>\n"
+" <entry>\n"
+" <key>serverBindPort</key>\n"
+" <value>\n"
+" <value-factory bean=\"ServiceBindingManager\" method=\"getStringBinding\">\n"
+" <parameter>HornetQConnector</parameter>\n"
+" <parameter>${port}</parameter>\n"
+" </value-factory>\n"
+" </value>\n"
+" </entry>\n"
+" ...\n"
+" <entry><key>marshaller</key> <value>org.jboss.jms.wireformat.JMSWireFormat</value></entry>\n"
+" <entry><key>unmarshaller</key> <value>org.jboss.jms.wireformat.JMSWireFormat</value></entry>\n"
+" </map\n"
+" </property>\n"
+" \n"
+" <!-- Parameters visible only to server -->\n"
+" <property name=\"serverParameters\">\n"
+" <map keyClass=\"java.lang.String\" valueClass=\"java.lang.String\">\n"
+" <entry><key>callbackTimeout</key> <value>10000</value></entry>\n"
+" </map>\n"
+" </property>\n"
+" \n"
+" ...\n"
+" </bean>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "In this version, the configuration information is expressed in the HornetQConfiguration <classname>ServerConfiguration</classname> POJO, which is then injected into the HornetQConnector <classname>org.jboss.remoting.transport.Connector</classname> POJO. The syntax is that of the Microcontainer, which is beyond the scope of this chapter. See <xref linkend=\"microcontainer\" /> for details. One variation from the MBean version is the use of the ServiceBindingManager, which is also beyond the scope of this chapter. Note that the @org.jboss.aop.microcontainer.aspects.jmx.JMX annotation causes the HornetQConnector to be visible as an MBean named \"jboss.messaging:service=Connector,transport=bisocket\"."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Multihomed servers"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Remoting can create servers bound to multiple interfaces. One application of this facility would be binding a server to one interface that faces the internet and another that faces a LAN. For example, the preceding POJO example can be modified by (1) adding POJOs"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" \n"
+" <bean name=\"homes1\" class=\"java.lang.StringBuffer\">\n"
+" <constructor>\n"
+" <parameter class=\"java.lang.String\">\n"
+" <value-factory bean=\"ServiceBindingManager\" method=\"getStringBinding\">\n"
+" <parameter>HornetQConnector:bindingHome1</parameter>\n"
+" <parameter>${host}:${port}</parameter>\n"
+" </value-factory>\n"
+" </parameter>\n"
+" </constructor>\n"
+" </bean>\n"
+" \n"
+" <bean name=\"homes2\" class=\"java.lang.StringBuffer\">\n"
+" <constructor factoryMethod=\"append\">\n"
+" <factory bean=\"homes1\"/>\n"
+" <parameter>\n"
+" <value-factory bean=\"ServiceBindingManager\" method=\"getStringBinding\">\n"
+" <parameter>HornetQConnector:bindingHome2</parameter>\n"
+" <parameter>!${host}:${port}</parameter>\n"
+" </value-factory>\n"
+" </parameter>\n"
+" </constructor>\n"
+" </bean> \n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "which results in a StringBuffer with a value something like (according to the ServiceBindingManager configuration values for HornetQConnector:bindingHome1 and HornetQConnector:bindingHome2) \"external.acme.com:5555!internal.acme.com:4444\", and (2) replacing the \"serverBindAddress\" and \"serverBindPort\" parameters with"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" <entry>\n"
+" <key>homes</key>\n"
+" <value><value-factory bean=\"homes2\" method=\"toString\"/></value>\n"
+" </entry>\n"
+" "
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "which transforms the StringBuffer into the String \"external.acme.com:5555!internal.acme.com:4444\" and injects it into the HornetQConnector. The resulting InvokerLocator will look like"
+msgstr ""
+
+#. Tag: programlisting
+#, no-c-format
+msgid "\n"
+" bisocket://multihome/?homes=external.acme.com:5555!internal.acme.com:\n"
+" 4444&marshaller=org.jboss.jms.wireformat.JMSWireFormat&\n"
+" unmarshaller=org.jboss.jms.wireformat.JMSWireFormat\n"
+" "
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Address translation"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Sometimes a server must be accessed through an address translating firewall, and a Remoting server can be configured with both a binding address/port and an address/port to be used by a client. Two more parameters are used: \"clientConnectAddress\" and \"clientConnectPort\". The \"serverBindAddress\" and \"serverBindPort\" values are used to create the server, and the values of \"clientConnectAddress\" and \"clientConnectPort\" are used in the InvokerLocator, which tells the client where the server is. There is also an analogous \"connecthomes\" parameter for multihome servers. In this case, \"homes\" is used to configure the server, and \"connecthomes\" tells the client where the server is."
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Where are they now?"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "The actual Remoting configuration files for the supported subsystems are as follows:"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "EJB2: ${JBOSS_HOME}/server/${CONFIG}/deploy/remoting-jboss-beans.xml"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "EJB3: ${JBOSS_HOME}/server/${CONFIG}/deploy/ejb3-connectors-jboss-beans.xml"
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "HornetQ: ${JBOSS_HOME}/server/${CONFIG}/deploy/messaging/remoting-bisocket-service.xml"
+msgstr ""
+
+#. Tag: title
+#, no-c-format
+msgid "Further information."
+msgstr ""
+
+#. Tag: para
+#, no-c-format
+msgid "Additional details may be found in the Remoting Guide at <ulink url=\"http://www.jboss.org/jbossremoting/docs/guide/2.5/html/index.html\"> http://www.jboss.org/jbossremoting/docs/guide/2.5/html/index.html</ulink>."
+msgstr ""
+
Added: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Revision_History.po
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Revision_History.po (rev 0)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/de-DE/Revision_History.po 2010-05-27 23:13:49 UTC (rev 105315)
@@ -0,0 +1,34 @@
+#
+# AUTHOR <EMAIL at ADDRESS>, YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: 0\n"
+"POT-Creation-Date: 2010-05-27T07:30:28\n"
+"PO-Revision-Date: 2010-05-27T07:30:28\n"
+"Last-Translator: Automatically generated\n"
+"Language-Team: None\n"
+"MIME-Version: 1.0\n"
+"Content-Type: application/x-publican; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Tag: title
+#, no-c-format
+msgid "Revision History"
+msgstr ""
+
+#. Tag: firstname
+#, no-c-format
+msgid "Laura"
+msgstr ""
+
+#. Tag: surname
+#, no-c-format
+msgid "Bailey"
+msgstr ""
+
+#. Tag: member
+#, no-c-format
+msgid "Fixing to build."
+msgstr ""
+
More information about the jboss-cvs-commits
mailing list