[jboss-cvs] JBossAS SVN: r78282 - projects/docs/community/5/Clustering_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Sep 9 19:52:24 EDT 2008
Author: skittoli at redhat.com
Date: 2008-09-09 19:52:23 -0400 (Tue, 09 Sep 2008)
New Revision: 78282
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JMS.xml
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JNDI.xml
Log:
updates
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JMS.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JMS.xml 2008-09-09 23:42:57 UTC (rev 78281)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JMS.xml 2008-09-09 23:52:23 UTC (rev 78282)
@@ -2,354 +2,77 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<chapter id="clustering-jms">
- <title>Clustered JMS Services</title>
-
- <para>JBoss AS 3.2.4 and above support high availability JMS (HA-JMS) services in the <literal>all</literal>
- server configuration. In the current production release of JBoss AS, the HA-JMS service is implemented
- as a clustered singleton fail-over service.
- </para>
-<note>
- <para>If you are willing to configure HA-JMS yourself, you can get it to work with earlier versions of JBoss AS. We have a customer who uses HA-JMS successfully in JBoss AS 3.0.7. Please contact JBoss support for more questions.
- </para>
-</note>
- <note>
- <para>
- The HA-JMS in JBoss AS 4.2.2 and earlier is based on JBoss MQ. In later releases of the AS, JBoss MQ has been be replaced by the newer JBoss Messaging project. JBoss Messaging's clustering implementation is considerably different from HA-JMS based on JBoss MQ; most notably it is not based on a singleton service only running on one node in the cluster.
- </para>
- </note>
-
-
-
-
-<section id="clustering-jms-singleton">
- <title>High Availability Singleton Fail-over</title>
- <para>The JBoss HA-JMS service (i.e., message queues topics and supporting services) only runs on a single node (i.e., the master node) in the cluster at any given time. If that node fails, the cluster simply elects another node to run the JMS service, and the queues, topics and supporting services are deployed on that server (fail-over). This setup provides redundancy against server failures but does not reduce the work load on the JMS server node.</para>
- <note>
- <para>While you cannot load balance HA-JMS queues (there is only one master node that runs the
- queues), you can load balance the MDBs that process messages from those queues (see <xref linkend="clustering-jms-loadbalanced"/>).</para>
- </note>
+ <title>JBoss Messaging Clustering Notes</title>
+
+ <section><title>Unique server peer id</title>
+ <para>
+ JBoss Messaging clustering should work out of the box in the <emphasis>all</emphasis> configuration with no configuration changes. It is however crucial that every node is assigned a unique server id.
+ </para>
+ <para>
+ Every node deployed must have a unique id, including those in a particular LAN cluster, and also those only linked by message bridges.
+ </para>
+ <para>
+ <xref linkend="messaging"/> outlines, specific messaging configuration settings referenced in this chapter.
+ </para>
+ </section>
+
+ <section><title>Clustered destinations</title>
+ <para>
+ JBoss Messaging clusters JMS queues and topics transparently across the cluster. Messages sent to a distributed queue or topic on one node are consumable on other nodes. To designate that a particular destination is clustered simply set the clustered attribute in the destination deployment descriptor to true.
+ </para>
+ <para>
+ JBoss Messaging balances messages between nodes, catering for faster or slower consumers to efficiently balance processing load across the cluster.
+ </para>
+ <para>
+ If you do not want message redistribution between nodes, but still want to retain the other characteristics of clustered destinations, you can specify the attribute <literal>ClusterPullConnectionFactoryName</literal> on the server peer.
+ </para>
+ </section>
+
+ <section><title>Clustered durable subs</title>
+
+ <para>
+ JBoss Messaging durable subscriptions can also be clustered. This means multiple subscribers can consume from the same durable subscription from different nodes of the cluster. A durable subscription will be clustered if it's topic is clustered.
+ </para>
+ </section>
+ <section><title>Clustered temporary destinations</title>
+
+ <para>
+ JBoss Messaging also supports clustered temporary topics and queues. All temporary topics and queues will be clustered if the post office is clustered.
+ </para>
+ </section>
+
+
+ <section><title>Non clustered servers</title>
+
+
+ <para>If you don't want your nodes to participate in a cluster, or only have one non clustered server you can set the clustered attribute on the postoffice to <literal>false</literal>.
+ </para>
+ </section>
+ <section><title>Message ordering in the cluster</title>
+
+ <para>
+ If you wish to apply strict JMS ordering to messages, such that a particular JMS consumer consumes messages in the same order as they were produced by a particular producer, you can set the <literal>DefaultPreserveOrdering</literal> attribute in the server peer to <literal>true</literal>. By default this is false.
+ </para>
+<note><title>Note</title><para>The side effect of setting this to true is that messages cannot be distributed as freely around the cluster.</para></note>
+</section>
-<section id="clustering-jms-singleton-server">
- <title>Server Side Configuration</title>
-
- <para>
- The biggest configuration difference between HA-JMS in the all configuration and the non-HA version found in the default configuration is the location of most configuration files. For HA-JMS, most configuration files are found in the deploy-hasingleton/jms directory, not in deploy/jms. Your queues and topics must be deployed in deploy-hasingleton (or a subdirectory of it like deploy-hasingleton/jms.) Application components that act as clients to HA-JMS (e.g., MDBs and other JMS clients) do not need to be deployed in deploy-hasingleton. They should only be deployed there if you only want them running on one node in the cluster at a time.
- </para>
- <para>
- To use the singleton fail-over HA-JMS service, you must configure JMS services identically on all nodes in the cluster. That includes all JMS related service MBeans and all deployed queues and topics. However, applications that use JMS (e.g., MDBs and other JMS clients) do not need to be deployed identically across the cluster.
- </para>
-
-
-
- <para>
- The JMS server is configured to persist its data in the <literal>DefaultDS</literal>. By default, that is the embedded HSQLDB. However, for the HA-JMS service fail-over to work, the newly started HA-JMS server needs to be able to find the data persisted by the old server. That's not likely to happen if the data is persisted in files written by the old servers' HSQLDB. In almost any cluster environments, all nodes need to persist data against a shared database. So, the first thing to do before you start clustered JMS is to setup a shared database for JMS. You need to do the following:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>Configure <literal>DefaultDS</literal> to point to the database server of your choice.
- That is to replace the <literal>deploy/hsqlsb-ds.xml</literal> file with the
- <literal>xxx-ds.xml</literal> file in the <literal>docs/examples/jca</literal>
- directory, where <literal>xxx</literal> is the name of the target shared database (e.g.,
- <literal>mysql-ds.xml</literal>).</para>
- </listitem>
- <listitem>
- <para>Replace the <literal>hsqldb-jdbc2-service.xml</literal> file under the
- <literal>server/all/deploy-hasingleton/jms</literal> directory with one tuned to the
- specific database. For example if you use MySQL the file is
- <literal>mysql-jdbc2-service.xml</literal>. Configuration files for a number of
- RDBMS are bundled with the JBoss AS distribution. They can be found under
- <literal>docs/examples/jms</literal>.</para>
- </listitem>
- </itemizedlist>
- <note>
- <para>There is no need to replace the <literal>hsqldb-jdbc-state-service.xml</literal> file
- under the <literal>server/all/deploy-hasingleton/jms</literal> directory. Despite the
- <literal>hsql</literal> in its name, it works with all SQL92 compliant databases,
- including HSQL, MySQL, SQL Server, and more. It automatically uses the
- <literal>DefaultDS</literal> for storage, which we configured above.</para>
- </note>
- </section>
-
-
-
- <section id="clustering-jms-singleton-client">
- <title>Non-MDB HA-JMS Clients </title>
-
- <para>The HA-JMS client is different from regular JMS clients in two important aspects.</para>
-
- <itemizedlist>
- <listitem>
- <para>
- The HA-JMS client must look up JMS connection factories as well as queues and topicsusing HA-JNDI (the default port is 1100). This ensures the factory/queue/topic can be found no matter which cluster node is running the HA-JMS server.
- </para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>
- If the client is a J2EE component (session bean or web application) running inside the AS, the lookup via HA-JNDI can be configured using the component's deployment descriptors: In the standard deployment descriptor (ejb-jar.xml or web.xml):
- </para>
- </listitem>
-
- </itemizedlist>
-
-
-<programlisting><![CDATA[
-<resource-ref>
- <res-ref-name>jms/ConnectionFactory</res-ref-name>
- <res-type>javax.jms.QueueConnectionFactory</res-type>
- <res-auth>Container</res-auth>
-</resource-ref>
-
-<resource-ref>
- <res-ref-name>jms/Queue</res-ref-name>
- <res-type>javax.jms.Queue</res-type>
- <res-auth>Container</res-auth>
-</resource-ref>
-]]></programlisting>
-<para>
-And in the JBoss-specific descriptor (jboss.xml or jboss-web.xml):
-</para>
-
-<programlisting><![CDATA[
-<resource-ref>
- <res-ref-name>jms/ConnectionFactory</res-ref-name>
- <!-- Use the JMS Resource Adapter, let it deal
- with knowing where the JMS server is -->
- <jndi-name>java:/JmsXA</jndi-name>
- </resource-ref>
-
-<resource-ref>
- <res-ref-name>jms/Queue</res-ref-name>
- <!-- Use HA-JNDI so we can find the queue on any node -->
- <jndi-name>jnp://localhost:1100/queue/A</jndi-name>
-</resource-ref>]]>
-</programlisting>
-
-
- <itemizedlist>
- <listitem>
- <para>
- The HA-JMS client must deal with exceptions that will occur on the JMS connection if server failover occurs. Unlike, for example, clustered EJB proxies, the JMS connection object does not include automatic failover logic. If the HA-JMS service fails over to a different master node, all client operations on the current connection will fail with a JMSException. To deal with this:
- </para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>If the client is running inside the application server, the client should obtain the ConnectionFactory by looking up java:/JmsXAin JNDI. This will find the JBoss JMS Resource Adapter; the resource adapter will handle the task of detecting server failover and reconnecting to the new server when it starts.
- </para>
- </listitem>
- <listitem>
- <para>For clients outside the application server, the best approach is to register an ExceptionListener with the connection; the listener will get a callback if there is an exception on the connection. The callback should then handle the task of closing the old connection and reconnecting. Following is a example application that continuously sends messages to a queue, handling any exceptions that occur:
- </para>
- </listitem>
- </itemizedlist>
-
-
-<programlisting><![CDATA[
-package com.test.hajms.client;
-
-import javax.naming.InitialContext;
-import javax.jms.ConnectionFactory;
-import javax.jms.Destination;
-import javax.jms.Connection;
-import javax.jms.Session;
-import javax.jms.MessageProducer;
-import javax.jms.Message;
-import javax.jms.ExceptionListener;
-import javax.jms.JMSException;
-import javax.jms.DeliveryMode;
-
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-
-public class FailoverJMSClient
-{
-private static final Log log = LogFactory.getLog(FailoverJMSClient.class);
-
-public static final int NUM_RETRIES = 3;
-
-volatile boolean doSend = true;
-ConnectionFactory connectionFactory;
-Destination queue;
-Connection connection;
-Session session;
-MessageProducer producer;
-
-
-public static void main(String[] args) throws Exception
-{
-FailoverJMSClient jmsClient = new FailoverJMSClient();
-jmsClient.setUpJMS();
-jmsClient.sendMessages();
-}
-
-
-public boolean setUpJMS()
-{
-InitialContext ic;
-try
-{
-// assume jndi.properties is configured for HA-JNDI
-ic = new InitialContext();
-connectionFactory = (ConnectionFactory)ic.lookup("ConnectionFactory");
-queue = (Destination)ic.lookup("queue/FailoverTestQueue");
-connection = connectionFactory.createConnection();
-try
-{
-log.debug("Connection created ...");
-
-// KEY - register for exception callbacks
-connection.setExceptionListener(new ExceptionListenerImpl());
-
-session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
-log.debug("Session created ...");
-producer = session.createProducer(queue);
-
-producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
-log.debug("Producer created ...");
-
-return true;
-}
-catch (Exception e)
-{
-// We failed so close the connection
-try
-{
-connection.close();
-}
-catch (JMSException ignored)
-{
-// Pointless
-}
-// Rethrow the initial problem to where we will log it
-throw e;
-}
-finally
-{
-// And close the initial context
-// We don't want to wait for the garbage collector to close it
-// otherwise we'll have useless hanging network connections
-ic.close();
-}
-}
-catch (Exception e)
-{
-log.error("Error setting up JMS", e);
-return false;
-}
-}
-
-public void sendMessages()
-{
-int cnt = 0;
-while(doSend)
-{
-try
-{
-Thread.sleep(100);
-
-Message m = session.createObjectMessage(new Integer(cnt++));
-producer.send(m);
-
-log.trace("message " + cnt + " sent");
-
-}
-catch(Exception e)
-{
-cnt--;
-log.error(e.getMessage());
-}
-}
-}
-
-
-
-private class ExceptionListenerImpl implements ExceptionListener
-{
-public void onException(JMSException e)
-{
-
-for(int i = 0; i < NUM_RETRIES; i++)
- {
- log.warn("Connection has problems, trying to re-create it, attempt " +
- (i + 1) + " ...");
-
- try
- {
- connection.close(); // unregisters the ExceptionListener
- }
- catch(Exception e2) {
- // I will get an Exception anyway, since the connection to the
- //server is broken, but close() frees up resources associated
- // with the connection
- }
-
- boolean setupOK = setUpJMS();
-
- if (setupOK)
- {
- log.info("Connection re-established");
- return;
- }
- else
- {
- log.warn("Re-creating connection failed, retrying ...");
- }
- }
-
- log.error("Cannot re-establish connection, giving up ...");
- doSend = false;
- }
- }
-}
-]]>
-</programlisting>
-
-
-
-<section><title>MDBs and HA-JMS Failover</title>
- <para>
- When you deploy an MDB in JBoss, JBoss' MDB container handles for you all issues associated with finding the cluster singleton HA-JMS server and with reconnecting to it if it fails over.
- </para>
+<section><title>Idempotent operations</title>
+ <para>
+ If the call to send a persistent message to a persistent destination returns successfully with no exception, then you can be sure that the message was persisted. However if the call doesn't return successfully e.g. if an exception is thrown, then you <emphasis>can't be sure the message wasn't persisted</emphasis>. This is because the failure might have occurred after persisting the message but before writing the response to the caller. This is a common attribute of any RPC type call: You can't tell by the call not returning that the call didn't actually succeed. Whether it's a web services call, a HTTP get request, an EJB invocation the same applies. The trick is to code your application so your operations are <emphasis>idempotent</emphasis> i.e. they can be repeated without getting the system into an inconsistent state. With a message system you can do this on the application level, by checking for duplicate messages, and discarding them if they arrive. Duplicate che!
cking is a very powerful technique that can remove the need for XA transactions in many cases.
+ </para>
+
+<section><title>Clustered connection factories</title>
+ <para>
+ If the supportsLoadBalancing attribute of the connection factory is set to true then consecutive create connection attempts will round robin between available servers. The first node to try is chosen randomly.
+ </para>
+ <para>
+ If the supportsFailover attribute of the connection factory is set to true then automatic failover is enabled. This will automatically failover from one server to another, transparently to the user, in case of failure.
+ </para>
+ <para>
+ If automatic failover is not required or you wish to do manual failover (JBoss MQ style) this can be set to false, and you can supply a standard JMS ExceptionListener on the connection which will be called in case of connection failure. You would then need to manually close the connection, lookup a new connection factory from HA JNDI and recreate the connection.
+ </para>
</section>
- </section>
-
-
-
- <section id="clustering-jms-loadbalanced">
- <title>Load Balanced HA-JMS MDBs</title>
- <para>While the HA-JMS queues and topics only run on a single node at a time, MDBs on multiple nodes
- can receive and process messages from the HA-JMS master node. The contested queues and topics
- result in load balancing behavior for MDBs. To enable loading balancing for MDBs, you can
- specify a receiver for the queue. The receiver records which node is waiting for a message and
- in which order the messages should be processed. JBoss provides three receiver implementations.</para>
- <itemizedlist>
- <listitem>
- <para>The <literal>org.jboss.mq.server.ReceiversImpl</literal> is the default implementation
- using a <literal>HashSet</literal>.</para>
- </listitem>
- <listitem>
- <para>The <literal>org.jboss.mq.server.ReceiversImplArrayList</literal> is the implementation
- using an <literal>ArrayList</literal>.</para>
- </listitem>
- <listitem>
- <para>The <literal>org.jboss.mq.server.ReceiversImplLinkedList</literal> is the
- implementation using a <literal>LinkedList</literal>.</para>
- </listitem>
- </itemizedlist>
- <para>You can specify the receiver implementation class name as an attribute in the MBean that
- defines the permanent JMS <literal>Queue</literal> or <literal>DestinationManager</literal> on
- each node. For best load balancing performance, we suggest you
- to use the <literal>ReceiversImplArrayList</literal> or
- <literal>ReceiversImplLinkedList</literal> implementations due to an undesirable implementation
- detail of <literal>HashSet</literal> in the JVM.</para>
- </section>
- </section>
-
- </chapter>
+</section>
+</chapter>
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JNDI.xml 2008-09-09 23:42:57 UTC (rev 78281)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_JNDI.xml 2008-09-09 23:52:23 UTC (rev 78282)
@@ -169,31 +169,89 @@
<para>
If you want to access HA-JNDI from inside the application server, you must explicitly get an InitialContext by passing in JNDI properties. The following code shows how to create a naming Context bound to HA-JNDI:
</para>
-<programlisting>
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY,
- "org.jnp.interfaces.NamingContextFactory");
- p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
- p.put(Context.PROVIDER_URL, "localhost:1100"); // HA-JNDI port.
- return new InitialContext(p);
-</programlisting>
+<programlisting role="JAVA">Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY,
+"org.jnp.interfaces.NamingContextFactory");
+p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
+p.put(Context.PROVIDER_URL, "localhost:1100"); // HA-JNDI port.
+return new InitialContext(p);</programlisting>
<para>
The Context.PROVIDER_URL property points to the HA-JNDI service configured in the HANamingService MBean (see the section called “JBoss configuration”).
</para>
+
<para>
+ However, this does not work in all cases, especially when running a multihomed cluster (several JBoss instances on one machine bound to different IPs). A safer method is not to specify the Context.PROVIDER_URL (which does not work in all scenarios) but the partition name property:
+</para>
+<programlisting role="JAVA">Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
+p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
+p.put("jnp.partitionName", "DefaultPartition"); // partition name.
+return new InitialContext(p);</programlisting>
+
+<para>
Do not attempt to simplify things by placing a jndi.properties file in your deployment or by editing the AS's conf/jndi.properties file. Doing either will almost certainly break things for your application and quite possibly across the application server. If you want to externalize your client configuration, one approach is to deploy a properties file not named jndi.properties, and then programatically create a Properties object that loads that file's contents.
</para>
+<section><title>Accessing HA-JNDI Resources from EJBs and WARs -- Environment Naming Context</title>
+ <para>If your HA-JNDI client is an EJB or servlet, the least intrusive way to configure the lookup of resources is to bind the resources to the environment naming context of the bean or webapp performing the lookup. The binding can then be configured to use HA-JNDI instead of a local mapping. Following is an example of doing this for a JMS connection factory and queue (the most common use case for this kind of thing.</para>
+ <para>Within the bean definition in the ejb-jar.xml or in the war's web.xml you will need to define two resource-ref mappings, one for the connection factory and one for the destination.</para>
+<programlisting role="XML"><resource-ref>
+ <res-ref-name>jms/ConnectionFactory</res-ref-name>
+ <res-type>javax.jms.QueueConnectionFactory</res-type>
+ <res-auth>Container</res-auth>
+</resource-ref>
+
+<resource-ref>
+ <res-ref-name>jms/Queue</res-ref-name>
+ <res-type>javax.jms.Queue</res-type>
+ <res-auth>Container</res-auth>
+</resource-ref></programlisting>
+
+<para>
+ Using these examples the bean performing the lookup can obtain the connection factory by looking up 'java:comp/env/jms/ConnectionFactory' and can obtain the queue by looking up 'java:comp/env/jms/Queue'.
+</para>
+<para>
+Within the JBoss-specific deployment descriptor (jboss.xml for EJBs, jboss-web.xml for a WAR) these references need to mapped to a URL that makes use of HA-JNDI.
+</para>
+<programlisting role="XML"><resource-ref>
+ <res-ref-name>jms/ConnectionFactory</res-ref-name>
+ <jndi-name>jnp://localhost:1100/ConnectionFactory</jndi-name>
+</resource-ref>
+
+<resource-ref>
+ <res-ref-name>jms/Queue</res-ref-name>
+ <jndi-name>jnp://localhost:1100/queue/A</jndi-name>
+ </resource-ref></programlisting>
+
+<para>The URL should be the URL to the HA-JNDI server running on the same node as the bean; if the bean is available the local HA-JNDI server should also be available. The lookup will then automatically query all of the nodes in the cluster to identify which node has the JMS resources available.
+</para>
+
</section>
+<section><title>Why do this programmatically and not just put this in a jndi.properties file?</title>
+<para>
+ The JBoss application server's internal naming environment is controlled by the <filename>conf/jndi.properties</filename> file, which should not be edited.
+</para>
+<para>
+ No other jndi.properties file should be deployed inside the application server because of the possibility of its being found on the classpath when it shouldn't and thus disrupting the internal operation of the server. For example, if an EJB deployment included a jndi.properties configured for HA-JNDI, when the server binds the EJB proxies into JNDI it will likely bind them into the replicated HA-JNDI tree and not into the local JNDI tree where they belong.
+</para>
+
+</section>
+
+<section><title>How can I tell if things are being bound into HA-JNDI that shouldn't be?</title>
+ <para>Go into the the jmx-console and execute the <literal>list</literal> operation on the <literal>jboss:service=JNDIView</literal> mbean. Towards the bottom of the results, the contents of the "HA-JNDI Namespace" are listed. Typically this will be empty; if any of your own deployments are shown there and you didn't explicitly bind them there, there's probably an improper jndi.properties file on the classpath. Please visit the following link for an example: <ulink url="http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104715">Problem with removing a Node from Cluster</ulink> </para>
+
+</section>
+
+</section>
+
+
<section><title>For clients running outside the application server</title>
<para>The JNDI client needs to be aware of the HA-JNDI cluster. You can pass a list of JNDI servers (i.e., the nodes in the HA-JNDI cluster) to the <literal>java.naming.provider.url</literal> JNDI setting in the <literal>jndi.properties</literal> file. Each server node is identified by its IP address and the JNDI port number. The server nodes are separated by commas (see <xref linkend="clustering-jndi-jboss"/> for how to configure the servers and ports).</para>
-<programlisting>
-java.naming.provier.url=server1:1100,server2:1100,server3:1100,server4:1100
- </programlisting>
+<programlisting>java.naming.provier.url=server1:1100,server2:1100,server3:1100,server4:1100</programlisting>
<para>When initialising, the JNP client code will try to get in touch with each server node from the
list, one after the other, stopping as soon as one server has been reached. It will then download
the HA-JNDI stub from this node.</para>
@@ -251,14 +309,13 @@
<title>JBoss configuration</title>
<para>The <literal>cluster-service.xml</literal> file in the <literal>all/deploy</literal> directory
includes the following MBean to enable HA-JNDI services.</para>
- <programlisting>
-<mbean code="org.jboss.ha.jndi.HANamingService"
- name="jboss:service=HAJNDI">
- <depends optional-attribute-name="ClusterPartition"
- proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
+<programlisting role="XML"><mbean code="org.jboss.ha.jndi.HANamingService"
+name="jboss:service=HAJNDI">
+<depends optional-attribute-name="ClusterPartition"
+proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
-<mbean>
- </programlisting>
+<mbean></programlisting>
+
<para>You can see that this MBean depends on the <literal>DefaultPartition</literal> MBean defined above it (discussed earlier in this chapter). In other configurations, you can put that
element in the <literal>jboss-service.xml</literal> file or any other JBoss configuration files in
the <literal>/deploy</literal> directory to enable HA-JNDI services. The available attributes for
More information about the jboss-cvs-commits
mailing list