[jboss-cvs] JBoss Messaging SVN: r1837 - trunk/docs/clustering/en/modules
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Dec 20 06:32:21 EST 2006
Author: ovidiu.feodorov at jboss.com
Date: 2006-12-20 06:32:19 -0500 (Wed, 20 Dec 2006)
New Revision: 1837
Modified:
trunk/docs/clustering/en/modules/about.xml
trunk/docs/clustering/en/modules/configuration.xml
trunk/docs/clustering/en/modules/installation.xml
trunk/docs/clustering/en/modules/introduction.xml
trunk/docs/clustering/en/modules/overview.xml
Log:
updated clustering documentation
Modified: trunk/docs/clustering/en/modules/about.xml
===================================================================
--- trunk/docs/clustering/en/modules/about.xml 2006-12-20 11:14:32 UTC (rev 1836)
+++ trunk/docs/clustering/en/modules/about.xml 2006-12-20 11:32:19 UTC (rev 1837)
@@ -3,7 +3,7 @@
<title>JBoss Messaging Clustering Introduction</title>
<para>
- This guide gives a brief overview of the features available in JBoss Messaging Clustering Alpha 1
+ This guide gives a brief overview of the features available in JBoss Messaging Clustering Beta 1
</para>
<para>
Modified: trunk/docs/clustering/en/modules/configuration.xml
===================================================================
--- trunk/docs/clustering/en/modules/configuration.xml 2006-12-20 11:14:32 UTC (rev 1836)
+++ trunk/docs/clustering/en/modules/configuration.xml 2006-12-20 11:32:19 UTC (rev 1837)
@@ -3,39 +3,34 @@
<title>JBoss Messaging Clustering Configuration</title>
<para>
- This section describes how to configure JBoss Messaging 1.2 Alpha clustering.
+ This section describes how to configure JBoss Messaging 1.2 Beta clustering.
</para>
<para>
Please note that the clustering configuration is likely to change before the 1.2 final release.
- In particular we will be adding the ability for JBoss Messaging to use a pre-configured JGroups multiplex channel
- when used inside JBoss Application Server.
+ In particular we will be adding the ability for JBoss Messaging to use a pre-configured JGroups
+ multiplex channel when used inside JBoss Application Server.
</para>
<section id="config">
<para>
- JBoss Messaging includes the concept of a "Post Office". Messages are posted at a Post Office and the Post Office routes the message
- to it's destination queues.
+ JBoss Messaging includes the concept of a "Post Office". Messages are posted at a Post Office and
+ the Post Office routes the message to it's destination queues.
</para>
<para>
- In the case of JMS we always have two Post Office
- instances running.
-
- The first, the Queue Post Office, routes messages to JMS Queues, and the Topic Post Office routes messages to JMS Topics.
- </para>
-
- <para>
- Internally JBoss Messaging only deals with the concepts of queues, and considers a topic to just be a set of queues (one for
+ Both queues and topics use the same 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).
</para>
<para>
- Therefore the Queue Post Office routes a message to one and only one queue, depending on the queue name, whereas a Topic Post Office routes a message
- to a set of queues (one for each subscription) depending on the topic name.
+ 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 subscription) depending on the topic name.
</para>
<para>
@@ -43,25 +38,29 @@
</para>
<para>
- Clustered Post Office instances in a cluster connect to each other via JGroups, and when routing messages instead of just routing to local
- queues as is the case with a non-clustered Post Office, they can also route messages to queues on other Clustered Post Office instances.
+ Clustered Post Office instances in a cluster connect to each other via JGroups, and when
+ routing messages instead of just routing to local queues as is the case with a non-clustered
+ Post Office, they can also route messages to queues on other Clustered Post Office instances.
This allows us to create distributed queues and distributed topics.
</para>
<para>
- In the current release of JBoss Messaging 1.2, the JGroups configuration for each Clustered Post Office is specified in the Post Office configuration.
+ In the current release of JBoss Messaging 1.2, the JGroups configuration for each Clustered
+ Post Office is specified in the Post Office configuration.
- The details of the JGroups configuration won't be discussed here since it is standard JGroups configuration.
+ The details of the JGroups configuration won't be discussed here since it is standard
+ JGroups configuration.
- For more information on JGroups configuration please consult http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups
+ For more information on JGroups configuration please consult
+ http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups
</para>
<para>An example of a Clustered Post Office configuration is shown below</para>
<programlisting>
<mbean code="org.jboss.messaging.core.plugin.ClusteredPostOfficeService"
- name="jboss.messaging:service=QueuePostOffice"
+ name="jboss.messaging:service=PostOffice"
xmbean-dd="xmdesc/ClusteredPostOffice-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
Modified: trunk/docs/clustering/en/modules/installation.xml
===================================================================
--- trunk/docs/clustering/en/modules/installation.xml 2006-12-20 11:14:32 UTC (rev 1836)
+++ trunk/docs/clustering/en/modules/installation.xml 2006-12-20 11:32:19 UTC (rev 1837)
@@ -20,7 +20,7 @@
where:
<itemizedlist>
<listitem>
- <filename>node-id</filename> is an integer that must be unique per cluster.
+ <filename>node-id</filename> is the unique node ID, an integer that must be unique per cluster.
</listitem>
<listitem>
<filename>port-config-label</filename> is a binding manager server configuration label.
@@ -89,7 +89,7 @@
<programlisting>
04:48:49,663 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' to JNDI name 'java:DefaultDS'
- 04:48:50,257 INFO [ServerPeer] JBoss Messaging 1.2.0.Alpha1 server [0] started
+ 04:48:50,257 INFO [ServerPeer] JBoss Messaging 1.2.0.Beta1 server [0] started
04:48:50,569 INFO [STDOUT]
-------------------------------------------------------
GMS: address is 127.0.0.1:1473
Modified: trunk/docs/clustering/en/modules/introduction.xml
===================================================================
--- trunk/docs/clustering/en/modules/introduction.xml 2006-12-20 11:14:32 UTC (rev 1836)
+++ trunk/docs/clustering/en/modules/introduction.xml 2006-12-20 11:32:19 UTC (rev 1837)
@@ -3,12 +3,13 @@
<title>Introduction</title>
<para>
- JBoss Messaging 1.2 GA will provide a highly sophisticated clustering implementation, far more sophisticated than you'll find in the vast
- majority of other messaging systems.
+ JBoss Messaging 1.2 GA will provide a highly sophisticated clustering implementation, far
+ more sophisticated than you'll find in the vast majority of other messaging systems.
</para>
<para>
- It will allow you to smoothly distribute your application load across your cluster, intelligently balancing and utilising each nodes
- CPU cycles, with no single point of failure, providing a highly scalable and performant clustering implementation.
+ It will allow you to smoothly distribute your application load across your cluster,
+ intelligently balancing and utilising each nodes CPU cycles, with no single point of failure,
+ providing a highly scalable and performant clustering implementation.
</para>
<section id="features">
@@ -21,20 +22,23 @@
<itemizedlist>
<listitem>
<para>
- Distributed queues. Messages sent to a distributed queue while attached to a particular node will be routed
- to a queue instance on a particular node according to a routing policy
+ Distributed queues. Messages sent to a distributed queue while attached to a
+ particular node will be routed to a queue instance on a particular node according
+ to a routing policy.
</para>
</listitem>
<listitem>
<para>
- Distributed topics. Messages sent to a distributed topic while attached at a particular node will be received by subscriptions on other nodes.
+ Distributed topics. Messages sent to a distributed topic while attached at a
+ particular node will be received by subscriptions on other nodes.
</para>
</listitem>
<listitem>
<para>
Fully reliable message distribution. Once and only once delivery is fully guaranteed.
When sending messages to a topic with multiple durable subscriptions
- across a cluster we guarantee that message reaches all the subscriptions (or none of them in case of failure).
+ across a cluster we guarantee that message reaches all the subscriptions
+ (or none of them in case of failure).
</para>
</listitem>
<listitem>
@@ -77,17 +81,19 @@
</section>
<section id="alphafeatures">
- <title>JBoss Messaging 1.2 Alpha 1 features:</title>
+ <title>JBoss Messaging 1.2 Beta 1 features:</title>
- <para> What's in the Alpha 1 release?</para>
+ <para> What's in the Beta 1 release?</para>
<para>
- JBoss Messaging Alpha 1, is the first experimental release of the JBoss Messaging clustering functionality.
+ JBoss Messaging Beta 1 contains a significant percentage of the functionality planned for the
+ GA release.
</para>
<para>
- Please note that this is an Alpha and will contain bugs!
- We are releasing it to the community, so you can try it out, get familiar with it and feedback your experiences to us so we can improve it and stabilise it.
+ Please note that this is a Beta and will contain bugs!
+ We are releasing it to the community, so you can try it out, get familiar with it
+ and feedback your experiences to us so we can improve it and stabilise it.
</para>
<para>
@@ -95,42 +101,31 @@
</para>
<para>
- This release does not have the full clustering functionality that will be available in 1.2 GA.
- </para>
-
- <para>
All the final features are available apart from:
</para>
<itemizedlist>
<listitem>
<para>
- High availability. There is no seamless failover in alpha. If you are attached to a particular node and it crashes, then you will not fail over
- onto another node.
+ Persistent level reliability guarantee without persistence. There is no option for
+ in memory replication of persistent messages in this Beta release.
</para>
- <para>
- There is no HA JNDI support in alpha - when connecting to a particular node you must correct directly to JNDI at the node of interest.
- </para>
</listitem>
<listitem>
<para>
- Persistent level reliability guarantee without persistence. There is no option for in memory replication of persistent messages in Alpha.
+ Intelligent message distribution is available but disabled in the default configuration
+ because it is currently unstable. Stability should increase in the next Beta release (Beta2).
+ (For intrepid explorers - it is very straightforward to enable this if you wish -
+ see the configuration section - but watch out for unpredictable results.)
</para>
</listitem>
- <listitem>
- <para>
- Intelligent message distribution is available but disabled in the default configuration because it is currently unstable.
- Stability should increase over the next few weeks.
-(For intrepid explorers - it is very straightforward to enable this if you wish - see the configuration section - but watch out for unpredictable results.)
- </para>
- </listitem>
-
</itemizedlist>
<para>
- Bear in mind you will need to get a bit more "down and dirty" with the configuration in this release, than you would with a GA release.
+ Bear in mind you will need to get a bit more "down and dirty" with the configuration in
+ this release, than you would with a GA release.
</para>
</section>
Modified: trunk/docs/clustering/en/modules/overview.xml
===================================================================
--- trunk/docs/clustering/en/modules/overview.xml 2006-12-20 11:14:32 UTC (rev 1836)
+++ trunk/docs/clustering/en/modules/overview.xml 2006-12-20 11:32:19 UTC (rev 1837)
@@ -14,42 +14,48 @@
</para>
<para>
- Clustered destinations (queues and topics) can be deployed at all or none of the nodes of the cluster.
+ Clustered destinations (queues and topics) can be deployed at all or none of the nodes of
+ the cluster.
</para>
<para>
- A JMS client uses HA JNDI to lookup the connection factory. A client side load balancing policy will automatically chose a node to connect to (This is similar to
+ A JMS client uses HA JNDI to lookup the connection factory. A client side load balancing
+ policy will automatically chose a node to connect to (This is similar to
how EJB clustering chooses a node).
</para>
<para>
- The JMS client has now made a connection to a node where it can create sessions, message producers and message consumers and browsers and send or consume messages,
+ The JMS client has now made a connection to a node where it can create sessions, message
+ producers and message consumers and browsers and send or consume messages,
using the standard JMS api.
</para>
<para>
- When a distributed queue is deployed across the cluster, individual partial queues are deployed on each node.
+ When a distributed queue is deployed across the cluster, individual partial queues are
+ deployed on each node.
</para>
<para>
- When a message is sent from a message producer attached to a particular node to a distributed quueue, a routing policy determines which partial queue will receive
+ When a message is sent from a message producer attached to a particular node to a
+ distributed quueue, a routing policy determines which partial queue will receive
the message.
</para>
<para>
- By default the router will always pass the message to a local queue, if there is one, this is so we avoid unnecessary network traffic.
+ By default the router will always pass the message to a local queue, if there is one,
+ this is so we avoid unnecessary network traffic.
</para>
<para>
- If there is no local queue
- then a partial queue on a different node will be chosen by the router, by default this will be round robin between remote partial queues.
+ If there is no local queue then a partial queue on a different node will be chosen by the
+ router, by default this will be round robin between remote partial queues.
</para>
<para>
- When a message is sent to a distributed topic while attached to a node, there may be multiple subscriptions on different nodes that need to receive the
- message.
-
- Depending on the number and location of subscriptions, the message may be multicast or unicast across the cluster so the other nodes can pick it up.
+ When a message is sent to a distributed topic while attached to a node, there may be
+ multiple subscriptions on different nodes that need to receive the
+ message. Depending on the number and location of subscriptions, the message may be multicast
+ or unicast across the cluster so the other nodes can pick it up.
</para>
<para>
@@ -57,8 +63,8 @@
</para>
<para>
- In the case of shared durable subscriptions, if a durable subscription with the same name exists on more than node, then only one of the instances needs to
- receive the message.
+ In the case of shared durable subscriptions, if a durable subscription with the same name
+ exists on more than node, then only one of the instances needs to receive the message.
</para>
<para>Which one is determined by the same routing policy used to route messages to partial queues.</para>
@@ -93,17 +99,20 @@
</para>
<para>
- JBoss Messaging deals with this problem by intelligently pulling messages from other less busy nodes, if it detects idle consumers on the fast node and slow consumers
- on another node. (Please note that this functionality is currently unstable in the Alpha1 release).
+ JBoss Messaging deals with this problem by intelligently pulling messages from other less
+ busy nodes, if it detects idle consumers on the fast node and slow consumers
+ on another node. (Please note that this functionality is currently unstable in the Beta1
+ release).
</para>
<para>
- Another feature (not available in alpha 1) that will enable very fast, very scalable reliable messaging without using databases is in memory replication
- of reliable messages.
+ Another feature (not available in Beta 1) that will enable very fast, very scalable reliable
+ messaging without using databases is in memory replication of reliable messages.
</para>
<para>
- Normally, persistent messages are persisted in a shared database which is shared by all nodes in the cluster.
+ Normally, persistent messages are persisted in a shared database which is shared by all nodes
+ in the cluster.
JBoss Messaging 1.2.GA will contain
an option where you can choose to not persist persistent messages in a database, but instead to replicate them between nodes of the cluster.
More information about the jboss-cvs-commits
mailing list