[jboss-cvs] JBoss Messaging SVN: r2532 - in trunk/docs/userguide-1.2/en: modules and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Mar 1 05:52:35 EST 2007
Author: ovidiu.feodorov at jboss.com
Date: 2007-03-01 05:52:35 -0500 (Thu, 01 Mar 2007)
New Revision: 2532
Removed:
trunk/docs/userguide-1.2/en/modules/CLUST_about.xml
Modified:
trunk/docs/userguide-1.2/en/master.xml
trunk/docs/userguide-1.2/en/modules/CLUST_configuration.xml
trunk/docs/userguide-1.2/en/modules/CLUST_overview.xml
trunk/docs/userguide-1.2/en/modules/UG12_performance.xml
Log:
more doc work
Modified: trunk/docs/userguide-1.2/en/master.xml
===================================================================
--- trunk/docs/userguide-1.2/en/master.xml 2007-03-01 10:22:47 UTC (rev 2531)
+++ trunk/docs/userguide-1.2/en/master.xml 2007-03-01 10:52:35 UTC (rev 2532)
@@ -37,14 +37,10 @@
&UG12_performance;
- &C_about;
+ &C_overview;
- <!-- &C_introduction; -->
+ &C_installation;
- &C_overview;
-
- &C_installation;
-
- &C_configuration;
+ &C_configuration;
</book>
Deleted: trunk/docs/userguide-1.2/en/modules/CLUST_about.xml
===================================================================
--- trunk/docs/userguide-1.2/en/modules/CLUST_about.xml 2007-03-01 10:22:47 UTC (rev 2531)
+++ trunk/docs/userguide-1.2/en/modules/CLUST_about.xml 2007-03-01 10:52:35 UTC (rev 2532)
@@ -1,19 +0,0 @@
-<chapter id="CLUST_about">
-
-<title>JBoss Messaging Clustering</title>
-
- <para>
- This section of the userguide gives a brief overview of the features available in JBoss Messaging Clustering 1.2.0.GA
- </para>
-
- <para>
- It gives a high level explanation of how clustering works and shows you how to set up a simple
- cluster of JBoss Messaging servers.
- </para>
-
- <para>
- Please send your suggestions, updates or comments to the
- <ulink url="http://www.jboss.org/index.html?module=bb&op=viewforum&f=238">JBoss Messaging user forum</ulink>.
- </para>
-
-</chapter>
Modified: trunk/docs/userguide-1.2/en/modules/CLUST_configuration.xml
===================================================================
--- trunk/docs/userguide-1.2/en/modules/CLUST_configuration.xml 2007-03-01 10:22:47 UTC (rev 2531)
+++ trunk/docs/userguide-1.2/en/modules/CLUST_configuration.xml 2007-03-01 10:52:35 UTC (rev 2532)
@@ -9,68 +9,6 @@
behavior can be changed through configuration.
</para>
- <section id="clustering_configuration_overview">
- <title>Clustering Architectural Overview</title>
-
- <para>
- One of the fundamental Messaging Core building blocks is the "Post Office". A JBoss Messaging
- Post Office is message routing component, which accepts messages for delivery and synchronously
- forwards them to their destination queues or topic subscriptions.
- </para>
-
- <para>
- There is a single Post Office instance per JBoss Messaging server (cluster node). Both queues
- and topics deployed on a JBoss Messaging node are "plugged" into that Post Office instance.
- Internally JBoss Messaging only deals with the concepts of queues, and considers a topic to
- just be a set of queues (one for each subscription). Depending on the type of subscription -
- durable or non-durable - the corresponding queue saves messages to persistent storage or
- it just holds messages in memory and discards them when the non-durable subscription is closed.
- </para>
-
- <para>
- Therefore, for a JMS queue, the Post Office routes messages to one and only one core queue,
- depending on the queue name, whereas for a JMS topic, the Post Office routes a message
- to a set of core queues, one for each topic subscription, depending on the topic name.
- </para>
-
- <para>
- Clustering across multiple address spaces is achieved by clustering Post Office instances. Each
- JBoss Messaging cluster node runs a Clustered Post Office instance, which is aware of the presence
- of all other clustered Post Offices in the cluster. There is an one-to-one relationship between cluster
- nodes and clustered Post Office instances. So, naturally, the most important piece of clustering
- configuration is the <emphasis>clustered Post Office service configuration</emphasis>,
- covered in detail below.
- </para>
-
- <para>
- Clustered Post Office instances connect to each other via JGroups and they heavily rely on JGroups
- group management and notification mechanisms. <emphasis>JGroups stack configuration</emphasis>
- is an essential part of JBoss Messaging clustering configuration. JGroups configuration is only
- briefly addressed in this guide. Detailed information on JGroups can be found in JGroups
- release documentation or on-line at <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink>
- or <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>
- </para>
-
- <para>
- When routing messages, a clustered Post Office has a choice of forwarding the message to local
- queues or remote queues, plugged into remote Post Office instances that are part of the same
- cluster. Local queues are usually preferred, but if a local queue is part of a distributed queue, has
- no consumers, and other local queues part of the same distributed queue have consumers, messages
- can be automatically redistributed, subject of the message redistribution policy in effect. This allows
- us to create distributed queues and distributed topics. <emphasis>Message redistribution
- configuration</emphasis> is another subject that we will insist on.
- </para>
-
- <para>
- Please note that some elements of clustering configuration are likely to change before the 1.2 final release.
- In particular we will try to add the ability for JBoss Messaging to use a pre-configured JGroups
- multiplex channel when used inside JBoss Application Server, but this is subject to availability of a
- AS clustering service supporting a multiplexed JGroups channel; such a service is currently being
- worked on by the AS Clustering team.
- </para>
-
- </section>
-
<section id="clustered_postoffice_configuration">
<title>Clustered Post Office Configuration</title>
@@ -107,9 +45,9 @@
CHANNEL_ID BIGINT, IS_FAILED_OVER CHAR(1), FAILED_NODE_ID INTEGER)
INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND,
SELECTOR, CHANNEL_ID, IS_FAILED_OVER, FAILED_NODE_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
-DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND
+DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND
QUEUE_NAME=?
-LOAD_BINDINGS=SELECT NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, IS_FAILED_OVER,
+LOAD_BINDINGS=SELECT NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, IS_FAILED_OVER,
FAILED_NODE_ID FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME = ?
]]></attribute>
<attribute name="GroupName">DefaultPostOffice</attribute>
@@ -123,50 +61,50 @@
<attribute name="AsyncChannelConfig">
<config>
-<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true"
-mcast_send_buf_size="32000" mcast_port="45567" ucast_recv_buf_size="500000"
-use_incoming_packet_handler="false" mcast_addr="228.8.8.8"
-use_outgoing_packet_handler="true" loopback="true" ucast_send_buf_size="32000"
+<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true"
+mcast_send_buf_size="32000" mcast_port="45567" ucast_recv_buf_size="500000"
+use_incoming_packet_handler="false" mcast_addr="228.8.8.8"
+use_outgoing_packet_handler="true" loopback="true" ucast_send_buf_size="32000"
ip_ttl="32" bind_addr="127.0.0.1"/>
<AUTOCONF down_thread="false" up_thread="false"/>
<PING timeout="2000" down_thread="false" num_initial_members="3" up_thread="false"/>
<MERGE2 max_interval="10000" down_thread="false" min_interval="5000" up_thread="false"/>
<FD timeout="2000" max_tries="3" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
-<pbcast.NAKACK max_xmit_size="8192" down_thread="false" use_mcast_xmit="true" gc_lag="50"
+<pbcast.NAKACK max_xmit_size="8192" down_thread="false" use_mcast_xmit="true" gc_lag="50"
up_thread="false"
retransmit_timeout="100,200,600,1200,2400,4800"/>
<UNICAST timeout="1200,2400,3600" down_thread="false" up_thread="false"/>
-<pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false"
+<pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false"
max_bytes="0" up_thread="false"/>
<FRAG frag_size="8192" down_thread="false" up_thread="false"/>
<VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
-<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false"
+<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false"
join_retry_timeout="2000" up_thread="false" shun="true"/>
</config>
</attribute>
<attribute name="SyncChannelConfig">
<config>
-<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true"
-mcast_send_buf_size="32000" mcast_port="45568" ucast_recv_buf_size="500000"
-use_incoming_packet_handler="false" mcast_addr="228.8.8.8"
-use_outgoing_packet_handler="true" loopback="true" ucast_send_buf_size="32000"
+<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true"
+mcast_send_buf_size="32000" mcast_port="45568" ucast_recv_buf_size="500000"
+use_incoming_packet_handler="false" mcast_addr="228.8.8.8"
+use_outgoing_packet_handler="true" loopback="true" ucast_send_buf_size="32000"
ip_ttl="32" bind_addr="127.0.0.1"/>
<AUTOCONF down_thread="false" up_thread="false"/>
<PING timeout="2000" down_thread="false" num_initial_members="3" up_thread="false"/>
<MERGE2 max_interval="10000" down_thread="false" min_interval="5000" up_thread="false"/>
<FD timeout="2000" max_tries="3" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
-<pbcast.NAKACK max_xmit_size="8192" down_thread="false" use_mcast_xmit="true" gc_lag="50"
+<pbcast.NAKACK max_xmit_size="8192" down_thread="false" use_mcast_xmit="true" gc_lag="50"
up_thread="false"
retransmit_timeout="100,200,600,1200,2400,4800"/>
<UNICAST timeout="1200,2400,3600" down_thread="false" up_thread="false"/>
-<pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false"
+<pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false"
max_bytes="0" up_thread="false"/>
<FRAG frag_size="8192" down_thread="false" up_thread="false"/>
<VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
-<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false"
+<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false"
join_retry_timeout="2000" up_thread="false" shun="true"/>
<pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/>
</config>
Modified: trunk/docs/userguide-1.2/en/modules/CLUST_overview.xml
===================================================================
--- trunk/docs/userguide-1.2/en/modules/CLUST_overview.xml 2007-03-01 10:22:47 UTC (rev 2531)
+++ trunk/docs/userguide-1.2/en/modules/CLUST_overview.xml 2007-03-01 10:52:35 UTC (rev 2532)
@@ -1,12 +1,20 @@
<chapter id="CLUST_overview">
- <title>Clustering overview</title>
- <section id="description">
+ <title>JBoss Messaging Clustering</title>
+
+ <para>
+ This section of the userguide gives a brief overview of the features available in
+ JBoss Messaging Clustering 1.2.0.GA. It gives a high level explanation of how
+ clustering works and shows you how to set up a simple cluster of JBoss Messaging
+ servers.
+ </para>
+
+ <section id="clustering_overview">
<title>JBoss Messaging Clustering Overview</title>
<para>
- Here's a brief overview of how clustering works in JBoss Messaging 2.0.
+ Here's a brief overview of how clustering works in JBoss Messaging 1.2.
</para>
<para>As mentioned in the previous chapter, please note that not all this functionality is
@@ -132,4 +140,59 @@
</para>
</section>
+
+
+ <section id="clustering_architectural_overview">
+ <title>Clustering Architectural Overview</title>
+
+ <para>
+ One of the fundamental Messaging Core building blocks is the "Post Office". A JBoss Messaging
+ Post Office is message routing component, which accepts messages for delivery and synchronously
+ forwards them to their destination queues or topic subscriptions.
+ </para>
+
+ <para>
+ There is a single Post Office instance per JBoss Messaging server (cluster node). Both queues
+ and topics deployed on a JBoss Messaging node are "plugged" into that Post Office instance.
+ Internally JBoss Messaging only deals with the concepts of queues, and considers a topic to
+ just be a set of queues (one for each subscription). Depending on the type of subscription -
+ durable or non-durable - the corresponding queue saves messages to persistent storage or
+ it just holds messages in memory and discards them when the non-durable subscription is closed.
+ </para>
+
+ <para>
+ Therefore, for a JMS queue, the Post Office routes messages to one and only one core queue,
+ depending on the queue name, whereas for a JMS topic, the Post Office routes a message
+ to a set of core queues, one for each topic subscription, depending on the topic name.
+ </para>
+
+ <para>
+ Clustering across multiple address spaces is achieved by clustering Post Office instances. Each
+ JBoss Messaging cluster node runs a Clustered Post Office instance, which is aware of the presence
+ of all other clustered Post Offices in the cluster. There is an one-to-one relationship between cluster
+ nodes and clustered Post Office instances. So, naturally, the most important piece of clustering
+ configuration is the <emphasis>clustered Post Office service configuration</emphasis>,
+ covered in detail below.
+ </para>
+
+ <para>
+ Clustered Post Office instances connect to each other via JGroups and they heavily rely on JGroups
+ group management and notification mechanisms. <emphasis>JGroups stack configuration</emphasis>
+ is an essential part of JBoss Messaging clustering configuration. JGroups configuration is only
+ briefly addressed in this guide. Detailed information on JGroups can be found in JGroups
+ release documentation or on-line at <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink>
+ or <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>
+ </para>
+
+ <para>
+ When routing messages, a clustered Post Office has a choice of forwarding the message to local
+ queues or remote queues, plugged into remote Post Office instances that are part of the same
+ cluster. Local queues are usually preferred, but if a local queue is part of a distributed queue, has
+ no consumers, and other local queues part of the same distributed queue have consumers, messages
+ can be automatically redistributed, subject of the message redistribution policy in effect. This allows
+ us to create distributed queues and distributed topics. <emphasis>Message redistribution
+ configuration</emphasis> is another subject that we will insist on.
+ </para>
+
+ </section>
</chapter>
Modified: trunk/docs/userguide-1.2/en/modules/UG12_performance.xml
===================================================================
--- trunk/docs/userguide-1.2/en/modules/UG12_performance.xml 2007-03-01 10:22:47 UTC (rev 2531)
+++ trunk/docs/userguide-1.2/en/modules/UG12_performance.xml 2007-03-01 10:52:35 UTC (rev 2532)
@@ -2,7 +2,15 @@
<title>Generating Performance Benchmark Results</title>
- <para>As we discussed in <xref linkend="about"/>, the key advantage of JBoss Messaging is its superior performance. In fact, the JBoss Messaging comes with a set of standard performance test. You can run them on your server and generate your own performance benchmark results. In this chapter, we will show you how to run a JBoss Messaging server and a JBossMQ server side-by-side on a single machine, and compare their performance. To get the performance tests, you have to obtain the JBoss Messaging source code from CVS as described in <xref linkend="gettingstarted"/>.</para>
+ <para>
+ As we discussed in <xref linkend="UG2_about"/>, the key advantage of JBoss Messaging is
+ its superior performance. In fact, the JBoss Messaging comes with a set of standard
+ performance test. You can run them on your server and generate your own performance
+ benchmark results. In this chapter, we will show you how to run a JBoss Messaging server
+ and a JBossMQ server side-by-side on a single machine, and compare their performance.
+ To get the performance tests, you have to obtain the JBoss Messaging source code from SVN
+ as described in <xref linkend="UG2_gettingstarted"/>.
+ </para>
<para>
To get the performance tests, you first need to check out the source code and build the project. The location of the framework's source code will be
@@ -20,7 +28,14 @@
<section>
<title>Run JBoss Messaging and JBossMQ Side-by-side</title>
- <para>To run performance tests side-by-side on the same machine, we assume that you create two JBoss AS configurations with the JBoss Messaging and JBossMQ modules respectively. We assume that the JBoss Messaging module is installed in the <literal>server/messaging</literal> directory (see <xref linkend="installation"/>), and the default JBossMQ module is installed in <literal>server/jbossmq</literal> directory (just copy the original <literal>default</literal> directory that comes with the server).</para>
+ <para>
+ To run performance tests side-by-side on the same machine, we assume that you create
+ two JBoss AS configurations with the JBoss Messaging and JBossMQ modules respectively.
+ We assume that the JBoss Messaging module is installed in the
+ <literal>server/messaging</literal> directory (see <xref linkend="UG2_installation"/>),
+ and the default JBossMQ module is installed in <literal>server/jbossmq</literal>
+ directory (just copy the original <literal>default</literal> directory that comes with
+ the server).</para>
<para>Now, if you run the two configurations on the same server, there will be port conflicts. To avoid that, we use the JBoss <literal>ServiceBindingManager</literal> to increase the port numbers in the <literal>jbossmq</literal> configuration by 100 (i.e., the JNDI service will be available at port 1199 instead of 1099). To do that, un-comment the following line in <literal>server/jbossmq/conf/jboss-service.xml</literal></para>
More information about the jboss-cvs-commits
mailing list