[jboss-cvs] JBoss Messaging SVN: r7011 - trunk/docs/user-manual/en.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue May 26 05:11:46 EDT 2009
Author: jmesnil
Date: 2009-05-26 05:11:46 -0400 (Tue, 26 May 2009)
New Revision: 7011
Modified:
trunk/docs/user-manual/en/appserver-integration.xml
trunk/docs/user-manual/en/architecture.xml
trunk/docs/user-manual/en/client-reconnection.xml
trunk/docs/user-manual/en/clusters.xml
trunk/docs/user-manual/en/configuration-index.xml
trunk/docs/user-manual/en/configuring-transports.xml
trunk/docs/user-manual/en/core-bridges.xml
trunk/docs/user-manual/en/diverts.xml
trunk/docs/user-manual/en/duplicate-detection.xml
trunk/docs/user-manual/en/filter-expressions.xml
trunk/docs/user-manual/en/flow-control.xml
trunk/docs/user-manual/en/ha.xml
trunk/docs/user-manual/en/interoperability.xml
trunk/docs/user-manual/en/logging.xml
trunk/docs/user-manual/en/message-expiry.xml
trunk/docs/user-manual/en/messaging-concepts.xml
trunk/docs/user-manual/en/paging.xml
trunk/docs/user-manual/en/perf-tuning.xml
trunk/docs/user-manual/en/persistence.xml
trunk/docs/user-manual/en/project-info.xml
trunk/docs/user-manual/en/queue-attributes.xml
trunk/docs/user-manual/en/security.xml
trunk/docs/user-manual/en/send-guarantees.xml
trunk/docs/user-manual/en/thread-pooling.xml
trunk/docs/user-manual/en/using-core.xml
trunk/docs/user-manual/en/using-jms.xml
trunk/docs/user-manual/en/using-server.xml
trunk/docs/user-manual/en/wildcard-routing.xml
Log:
user manual proof-reading
* typos
* fixed use of xrefs
* fixed missing ids
Modified: trunk/docs/user-manual/en/appserver-integration.xml
===================================================================
--- trunk/docs/user-manual/en/appserver-integration.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/appserver-integration.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="appserver-integration">
- <title>Application Server Integration and JavaEE</title>
+ <title>Application Server Integration and Java EE</title>
<para>JBoss Messaging can be easily installed in JBoss Application Server 5.1 or JBoss
Enterprise Application Platform 5.1 or later. For details on installing JBoss Messaging in
the JBoss Application Server refer to quick-start guide.</para>
@@ -317,12 +317,12 @@
<section>
<title>Adapter Outbound configuration</title>
<para>The outbound configuration should remain unchanged as they define connection
- factories that are used by JavaEE components. These Connection Factories can be
+ factories that are used by Java EE components. These Connection Factories can be
defined inside a configuration file that matches the name <literal
>*-ds.xml</literal>. You'll find a default <literal>jms-ds.xml</literal>
configuration under the <literal>messaging.sar</literal> directory in the Jboss AS
deployment. The connection factories defined in the config file inherit their
- properties from the main <literal>ra.xml</literal> config but can also be
+ properties from the main <literal>ra.xml</literal> configuration but can also be
overridden, the following example show how to define one.</para>
<para>Please note that this configuration only applies to install the JBM resource
adapter in the JBoss Application Server. If you are using another JEE application
@@ -355,7 +355,7 @@
<title>Adapter Inbound configuration</title>
<para>The inbound configuration should again remain unchanged. This controls what
forwards messages onto MDB's. It is possible to override properties on the MDB by
- adding an activation config to the MDB itself. This could be used to configure the
+ adding an activation configuration to the MDB itself. This could be used to configure the
MDB to consume from a different server. The next section demonstrates over riding
the configuration.</para>
</section>
@@ -449,15 +449,15 @@
<para>The bridge can also be used to bridge messages from other non JBoss Messaging JMS
servers, as long as they are JMS 1.1 compliant.<note>
<para>Don't confuse a JMS bridge with a core bridge. A JMS bridge can be used to
- bridge any two JMS 1.1 compliant JMS providers and uses the JMS API. A <xref
- linkend="core-bridges">core bridge</xref> is used to bridge any two JBoss
+ bridge any two JMS 1.1 compliant JMS providers and uses the JMS API. A core bridge
+ (described in <xref linkend="core-bridges" />) is used to bridge any two JBoss
Messaging instances and uses the core API. Always use a core bridge if you can
in preference to a JMS bridge. The core bridge will typically provide better
performance than a JMS bridge. Also the core bridge can provide <emphasis>once
and only once</emphasis> delivery guarantees without using XA.</para>
</note></para>
<para>The bridge has built in resilience to failure so if the source or target server
- connetion is lost, e.g. due to network failure, the bridge will retry connecting to the
+ connection is lost, e.g. due to network failure, the bridge will retry connecting to the
source and/or target until they come back online. When it comes back online it will
resume operation as normal.</para>
<para>The bridge can be configured with an optional JMS selector, so it will only consume
@@ -593,7 +593,7 @@
</bean>
</deployment></programlisting>
- <para>TODO TODO - please copy the documentation on these params from the JBM 1.4 docs</para>
+ <para>TODO TODO - please copy the documentation on these parameters from the JBM 1.4 docs</para>
<para>The main bean deployed is the <literal>JMSBridge</literal> bean. A description of each
of its constructor parameters in order follows:</para>
<itemizedlist>
@@ -737,7 +737,7 @@
</section>
<section>
<title>Example</title>
- <para>The <xref linkend="jms-bridge-example">jms bridge example</xref> shows how to
+ <para>Please see <xref linkend="jms-bridge-example" /> which shows how to
configure and use a JMS Bridge to send messages to the source destination and
consume them from the target destination.</para>
</section>
@@ -778,7 +778,7 @@
</section>
<section>
<title>Example</title>
- <para>The <xref linkend="xa-recovery-example">xa recovery example</xref> shows how to
+ <para>See <xref linkend="xa-recovery-example"/> which shows how to
configure XA Recovery and recover messages after a server crash.</para>
</section>
</section>
Modified: trunk/docs/user-manual/en/architecture.xml
===================================================================
--- trunk/docs/user-manual/en/architecture.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/architecture.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -45,7 +45,7 @@
<para>
<graphic fileref="images/architecture1.jpg" align="center"/>
</para>
- <para>Figure 3.1 shows two user applications interacting with a JBoss Mesaging server. User
+ <para>Figure 3.1 shows two user applications interacting with a JBoss Messaging server. User
Application 1 is using the JMS API, while User Application 2 is using the core client
API directly.</para>
<para>You can see from the diagram that the JMS API is implemented by a thin facade layer on
@@ -57,8 +57,8 @@
application that requires messaging functionality internally but you don't want to
expose that as a messaging server you can directly instantiate and embed messaging
servers in your own application.</para>
- <para>For more information on embedding JBoss Messaging see the chapter on <xref
- linkend="embedding-jbm">embedding</xref>.</para>
+ <para>For more information on embedding JBoss Messaging, see <xref
+ linkend="embedding-jbm" />.</para>
</section>
<section>
<title>JBoss Messaging integrated with a JEE application server</title>
@@ -72,7 +72,7 @@
system.</para>
<para>According to the JEE specification, a JEE application server uses a JCA adapter to
integrate with a JMS messaging system so it can consume messages for MDBs.</para>
- <para>Howvever, the JCA adapter is not only used by the JEE application server for <emphasis
+ <para>However, the JCA adapter is not only used by the JEE application server for <emphasis
role="italic">consuming</emphasis> messages via MDBs, it is also used when sending
message to the JMS messaging system e.g. from inside an EJB or servlet.</para>
<para>When integrating with a JMS messaging system from inside a JEE application server it
@@ -83,7 +83,7 @@
an EJB, MDB or servlet without going through a JCA adapter, but this is not recommended
since you will not be able to take advantage of the JCA features, such as caching of JMS
sessions, which can result in poor performance.</para>
- <para>Figure 3.2 belows shows a JEE application server integrating with a JBoss Messaging
+ <para>Figure 3.2 below shows a JEE application server integrating with a JBoss Messaging
server via the JBoss Messaging JCA adaptor. Note that all communication between EJB
sessions or entity beans and Message Driven beans go through the adaptor and not
directly to JBoss Messaging.</para>
@@ -94,8 +94,8 @@
<para>
<graphic fileref="images/architecture2.jpg"/>
</para>
- <para>For more information on using the JCA adaptor, please see the chatper on <xref
- linkend="appserver-integration">application server integration</xref>.</para>
+ <para>For more information on using the JCA adaptor, please see <xref
+ linkend="appserver-integration" />.</para>
</section>
<section>
<title>JBoss Messaging stand-alone server</title>
@@ -104,12 +104,12 @@
<para>The standard stand-alone messaging server configuration comprises a core messaging
server, a JMS service and a JNDI service.</para>
<para>The role of the JMS Service is to deploy any JMS Queues, Topics and ConnectionFactory
- instances from any server side <literal>jbm-jms.xml</literal> config files. It also
+ instances from any server side <literal>jbm-jms.xml</literal> configuration files. It also
provides a simple management API for creating and destroying Queues, Topics and
ConnectionFactory instances which can be accessed via JMX or the connection. It is a
separate service to the JBoss Messaging core server, since the core server is JMS
agnostic. If you don't want to deploy any JMS Queues, Topics and ConnectionFactory
- instances via server side xml config and don't require a JMS management API on the
+ instances via server side XML configuration and don't require a JMS management API on the
server side then you can disable this service.</para>
<para>We also include a JNDI server since JNDI is a common requirement when using JMS to
lookup Queues, Topics and ConnectionFactory instances. If you do not require JNDI then
@@ -123,7 +123,7 @@
<para>
<graphic fileref="images/architecture3.jpg"/>
</para>
- <para>For more information on serve configuration files see the chapter <xref linkend="">using the server</xref>.
- </para>
+ <para>For more information on server configuration files see <xref linkend="server.configuration" />.
+$ </para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/client-reconnection.xml
===================================================================
--- trunk/docs/user-manual/en/client-reconnection.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/client-reconnection.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -6,7 +6,7 @@
client successfully reconnects, and the server still has a record of the clients session
(i.e. the server was not restarted) then the client will transparently re-attach to the
session and it will be able to resume as if nothing had happened.</para>
- <para>Client reconnnection is also used internally by components such as core bridges to allow
+ <para>Client reconnection is also used internally by components such as core bridges to allow
them to reconnect to their target servers.</para>
<para>Client reconnection is configured using the following parameters:</para>
<itemizedlist>
@@ -54,10 +54,10 @@
</connection-factory>
</programlisting>
<para>If you're using JMS, but instantiating your JMS connection factory directly, you can
- specify the params using the appopriate setter methods on the <literal
+ specify the parameters using the appropriate setter methods on the <literal
>JBossConnectionFactory</literal> immediately after creating it.</para>
<para>If you're using the core API and instantiating the <literal>ClientSessionFactory</literal>
- instance directly you can also specify the params using the appopriate setter methods on the
+ instance directly you can also specify the parameters using the appropriate setter methods on the
<literal>ClientSessionFactory</literal> immediately after creating it.</para>
<para>If your client does manage to reconnect but the session is no longer available on the
server, for instance if the server has been restarted or it has timed out, then the client
Modified: trunk/docs/user-manual/en/clusters.xml
===================================================================
--- trunk/docs/user-manual/en/clusters.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/clusters.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -14,8 +14,9 @@
default.</para>
<para>The cluster is formed by each node declaring <emphasis>cluster connections</emphasis>
to other nodes in the core configuration file <literal>jbm-configuration.xml</literal>.
- When a node forms a cluster connection to another node, internally it creates a <xref
- linkend="core-bridges">core bridge</xref> connection between it and the other node,
+ When a node forms a cluster connection to another node, internally it creates a <emphasis>core
+ bridge</emphasis> (as described in <xref
+ linkend="core-bridges" />) connection between it and the other node,
this is done transparently behind the scenes - you don't have to declare an explicit
bridge for each node. These cluster connections allow messages to flow between the nodes
of the cluster to balance load.</para>
@@ -28,7 +29,7 @@
servers can broadcast their connection details so clients or other servers can connect
to them with the minimum of configuration.</para>
</section>
- <section>
+ <section id="clusters.server-discovery">
<title>Server discovery</title>
<para>Server discovery is a mechanism by which servers can broadcast their connection
settings across the network. This is useful for two purposes:</para>
@@ -55,8 +56,8 @@
<title>Broadcast Groups</title>
<para>A broadcast group is the means by which a server broadcasts connectors over the
network. A connector defines a way in which a client (or other server) can make
- connections to the server. For more information on what a connector is please see
- <xref linkend="configuring-transports">here</xref>.</para>
+ connections to the server. For more information on what a connector is, please see
+ <xref linkend="configuring-transports" />.</para>
<para>The broadcast group takes a set of connector pairs, each connector pair contains
connection settings for a live and (optional) backup server and broadcasts them on
the network. It also defines the UDP address and port settings. </para>
@@ -115,11 +116,11 @@
</listitem>
<listitem>
<para><literal>connector-ref</literal>. This specifies the connector and
- optional backup connector that will be broadcast. Please see <xref
- linkend="configuring-transports">here</xref> for more information on
- connectors. The connector to be broadcast is specified by the <literal
+ optional backup connector that will be broadcasted (see <xref
+ linkend="configuring-transports" /> for more information on
+ connectors). The connector to be broadcasted is specified by the <literal
>connector-name</literal> attribute, and the backup connector to be
- broadcast is specified by the <literal>backup-connector</literal> attribute.
+ broadcasted is specified by the <literal>backup-connector</literal> attribute.
The <literal>backup-connector</literal> attribute is optional.</para>
</listitem>
</itemizedlist>
@@ -266,7 +267,8 @@
<para>If cluster connections are defined between nodes of a cluster, then JBoss Messaging
will load balance messages arriving from at a particular node from a client.</para>
<para>Let's take a simple example of a cluster of four nodes A, B, C, and D arranged in a
- <xref linkend="symmetric-cluster">symmetric cluster</xref>. We have a queue called
+ <emphasis>symmetric cluster</emphasis> (described in <xref linkend="symmetric-cluster" />).
+ We have a queue called
<literal>OrderQueue</literal> deployed on each node of the cluster.</para>
<para>We have client Ca connected to node A, sending orders to the server. We have also have
order processor clients Pa, Pb, Pc, and Pd connected to each of the nodes A, B, C, D. If
@@ -351,8 +353,8 @@
filtered out and ignored on receipt at the target node.</para>
<para>This parameter has the same meaning as <literal
>use-duplicate-detection</literal> on a bridge. For more information on
- duplicate detection please <xref linkend="duplicate-detection"
- >here</xref>.</para>
+ duplicate detection, please see <xref linkend="duplicate-detection"
+ />.</para>
<para>This parameter is optional and has a default value of <literal
>true</literal>.</para>
</listitem>
@@ -500,7 +502,7 @@
connector. The <literal>backup-connector-name</literal> is optional, and if
specified it also references a connector defined in <literal
>jbm-configuration.xml</literal>. For more information on connectors please
- see <xref linkend="configuring-transports">here</xref>.</para>
+ see <xref linkend="configuring-transports" />.</para>
<para>The connection factory thus maintains a list of [connector, backup connector]
pairs, these pairs are then used by the client connection load balancing policy
on the client side when creating connections to the cluster.</para>
@@ -554,8 +556,8 @@
<para>In the above snippet we create a list of pairs of <literal
>TransportConfiguration</literal> objects. Each <literal
>TransportConfiguration</literal> object contains knowledge of how to make a
- connection to a specific server. For more information on this please see the
- chapter on <xref linkend="configuring-transports">connectors</xref>.</para>
+ connection to a specific server. For more information on this, please see
+ <xref linkend="configuring-transports" />.</para>
<para>A <literal>ClientSessionFactoryImpl</literal> instance is then created passing
the list of servers in the constructor. Any sessions subsequently created by
this factory will create sessions according to the client connection load
@@ -588,7 +590,7 @@
>jbm-configuration.xml</literal> which will be used as a live connector. The
<literal>backup-connector-name</literal> is optional, and if specified it also
references a connector defined in <literal>jbm-configuration.xml</literal>. For more
- information on connectors please see chapter [LINK].</para>
+ information on connectors please see <xref linkend="configuring-transports" />.</para>
</section>
</section>
<section id="clusters.message-redistribution">
@@ -611,7 +613,7 @@
disabled.</para>
<para>Message redistribution can be configured on a per address basis, by specifying the
redistribution delay in the address settings, for more information on configuring
- address settings please see <xref linkend="queue-attributes">here</xref>.</para>
+ address settings, please see <xref linkend="queue-attributes" />.</para>
<para>Here's an address settings snippet from <literal>jbm-configuration.xml</literal>
showing how message redistribution is enabled for a set of queues:</para>
<programlisting><address-settings>
@@ -625,8 +627,8 @@
to addresses that start with "jms.", so the above would enable instant (no delay)
redistribution for all JMS queues and topic subscriptions.</para>
<para>The attribute <literal>match</literal> can be an exact match or it can be a string
- that conforms to the JBoss Messaging wildcard syntax. <xref linkend="wildcard-syntax"
- /></para>
+ that conforms to the JBoss Messaging wildcard syntax (described in <xref linkend="wildcard-syntax"
+ />).</para>
<para>The element <literal>redistribution-delay</literal> defines the delay in milliseconds
after the last consumer is closed on a queue before redistributing messages from that
queue to other nodes of the cluster which do have matching consumers. A delay of zero
Modified: trunk/docs/user-manual/en/configuration-index.xml
===================================================================
--- trunk/docs/user-manual/en/configuration-index.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/configuration-index.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -3,7 +3,7 @@
<title>Configuration Reference</title>
<para>This section is a quick index for looking up configuration. Click on the element name to
go to the specific chapter.</para>
- <section>
+ <section id="server.configuration">
<title>Server Configuration</title>
<section>
<title>jbm-configuration.xml</title>
@@ -478,7 +478,7 @@
<entry><link linkend="core-bridges"
>bridges.forwarding-address</link></entry>
<entry>String</entry>
- <entry>Address to forward to. If ommitted original destination is
+ <entry>Address to forward to. If omitted original destination is
used.</entry>
<entry>null</entry>
</row>
@@ -897,7 +897,7 @@
<entry><link linkend="clusters-discovery.groups.clientside"
>connection-factory.discovery-initial-wait-timeout</link></entry>
<entry>long</entry>
- <entry>The initail time to wait, in milliseconds, for discovery groups
+ <entry>The initial time to wait, in milliseconds, for discovery groups
to wait for broadcasts</entry>
<entry>2000</entry>
</row>
Modified: trunk/docs/user-manual/en/configuring-transports.xml
===================================================================
--- trunk/docs/user-manual/en/configuring-transports.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/configuring-transports.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -41,7 +41,7 @@
the set of valid key-value pairs depends on the specific transport be used and are
passed straight through to the underlying transport.</para>
<para>Examples of key-value pairs for a particular transport would be, say, to configure the
- ip address to bind to, or the port to listen at.</para>
+ IP address to bind to, or the port to listen at.</para>
<para>Keys are always strings and values can be of type Long, Integer, String or
Boolean.</para>
</section>
Modified: trunk/docs/user-manual/en/core-bridges.xml
===================================================================
--- trunk/docs/user-manual/en/core-bridges.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/core-bridges.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -14,7 +14,7 @@
servers.</para>
<para>Bridges can be configured provide <emphasis>once and only once</emphasis> delivery
guarantees even in the event of the failure of the source or the target server. They do this
- by using <xref linkend="duplicate-detection">duplicate detection</xref>.</para>
+ by using duplicate detection (described in <xref linkend="duplicate-detection" />).</para>
<note>
<para>Although they have similar function, don't confuse core bridges with JMS
bridges!</para>
@@ -69,12 +69,12 @@
>jbm-jms.xml</literal> is loaded after the core configuration file
<literal>jbm-configuration.xml</literal> is loaded. If your bridge is
consuming from a JMS queue then you'll need to make sure the JMS queue is
- also deployed as a core queue in the core config. Take a look at the bridge
+ also deployed as a core queue in the core configuration. Take a look at the bridge
example for an example of how this is done.</para>
</note>
</listitem>
<listitem>
- <para><literal>forwarding-address</literal>.This is the address on the target server
+ <para><literal>forwarding-address</literal>. This is the address on the target server
that the message will be forwarded to. If a forwarding address is not specified
then the original destination of the message will be retained.</para>
</listitem>
@@ -82,8 +82,7 @@
<para><literal>filter-string</literal>. An optional filter string can be supplied.
If specified then only messages which match the filter expression specified in
the filter string will be forwarded. The filter string follows the JBoss
- Messaging <xref linkend="filter-expressions">filter expression
- syntax</xref>.</para>
+ Messaging filter expression syntax described in <xref linkend="filter-expressions" />.</para>
</listitem>
<listitem>
<para><literal>transformer-class-name</literal>. An optional transformer-class-name
@@ -149,9 +148,8 @@
duplicate detection allows these duplicates to be screened out and
ignored.</para>
<para>This allows the bridge to provide a <emphasis>once and only once</emphasis>
- delivery guarantee without using heavyweight methods such as XA.</para>
- <para>For more information on duplicate detection see <xref
- linkend="duplicate-detection">here</xref>.</para>
+ delivery guarantee without using heavyweight methods such as XA (see <xref
+ linkend="duplicate-detection" /> for more information).</para>
<para>The default value for this parameter is <literal>true</literal>.</para>
</listitem>
<listitem>
@@ -160,8 +158,8 @@
connection to the target server.</para>
<para>A <emphasis>connector</emphasis> encapsulates knowledge of what transport to
use (TCP, SSL, HTTP etc) as well as the server connection parameters (host, port
- etc). For more information about what connectors are and how to configure them
- please see <xref linkend="configuring-transports">here</xref>.</para>
+ etc). For more information about what connectors are and how to configure them,
+ please see <xref linkend="configuring-transports" />.</para>
<para>The <literal>connector-ref</literal> element can be configured with two
attributes:</para>
<itemizedlist>
Modified: trunk/docs/user-manual/en/diverts.xml
===================================================================
--- trunk/docs/user-manual/en/diverts.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/diverts.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -27,7 +27,7 @@
geographically distributed servers, creating your global messaging mesh.</para>
<para>Diverts are defined as xml in the <literal>jbm-configuration.xml</literal> file. There can
be zero or more diverts in the file.</para>
- <para>Please see the <xref linkend="divert-example">divert example</xref> for a full working
+ <para>Please see <xref linkend="divert-example" /> for a full working
example showing you how to configure and use diverts.</para>
<para>Let's take a look at some divert examples:</para>
<section>
Modified: trunk/docs/user-manual/en/duplicate-detection.xml
===================================================================
--- trunk/docs/user-manual/en/duplicate-detection.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/duplicate-detection.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -109,8 +109,8 @@
>use-duplicate-detection</parameter> to <literal>true</literal> when configuring a
bridge in <literal>jbm-configuration.xml</literal>.</para>
<para>The default value for this parameter is <literal>true</literal>.</para>
- <para>For more information on core bridges and how to configure them see the chapter on
- <xref linkend="core-bridges">core bridges</xref>.</para>
+ <para>For more information on core bridges and how to configure them, please see
+ <xref linkend="core-bridges" />.</para>
</section>
<section>
<title>Duplicate Detection and Cluster Connections</title>
@@ -121,15 +121,15 @@
<parameter>use-duplicate-detection</parameter> to <literal>true</literal> when
configuring a cluster connection in <literal>jbm-configuration.xml</literal>.</para>
<para>The default value for this parameter is <literal>true</literal>.</para>
- <para>For more information on cluster connections and how to configure them see <xref
- linkend="clusters">here</xref>.</para>
+ <para>For more information on cluster connections and how to configure them, please see <xref
+ linkend="clusters"/>.</para>
</section>
<section>
<title>Duplicate Detection and Paging</title>
<para>JBoss Messaging also uses duplicate detection when paging messages to storage. This is
so when a message is depaged from storage and server failure occurs, we do not end up
depaging the message more than once which could result in duplicate delivery.</para>
- <para>For more information on paging and how to configure it please see <xref
- linkend="paging">here</xref>.</para>
+ <para>For more information on paging and how to configure it, please see <xref
+ linkend="paging" />.</para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/filter-expressions.xml
===================================================================
--- trunk/docs/user-manual/en/filter-expressions.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/filter-expressions.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -17,16 +17,15 @@
</listitem>
<listitem>
<para>Core bridges can be defined with an optional filter expression, only matching
- messages will be bridged. See the chapter on <xref linkend="core-bridges"
- >bridges</xref>.</para>
+ messages will be bridged (see <xref linkend="core-bridges"/>).</para>
</listitem>
<listitem>
<para>Diverts can be defined with an optional filter expression, only matching messages
- will be diverted. See the chapter on <xref linkend="diverts">diverts</xref>.</para>
+ will be diverted (see <xref linkend="diverts" />).</para>
</listitem>
<listitem>
<para>Filter are also used programmatically when creating consumers, queues and in
- several places in the <xref linkend="management">management</xref> API.</para>
+ several places as described in <xref linkend="management"/>.</para>
</listitem>
</itemizedlist>
<para>There are some differences between JMS selector expressions and JBoss Messaging core
Modified: trunk/docs/user-manual/en/flow-control.xml
===================================================================
--- trunk/docs/user-manual/en/flow-control.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/flow-control.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -31,9 +31,9 @@
<para><literal>-1</literal> for an <emphasis>unbounded</emphasis> buffer</para>
</listitem>
<listitem>
- <para><literal>0</literal> to not buffer any messages. See the <xref
- linkend="no-consumer-buffering-example">no consumer buffering example</xref>
- for working example of this.</para>
+ <para><literal>0</literal> to not buffer any messages. See <xref
+ linkend="no-consumer-buffering-example" />
+ for working example of a consumer with no buffering.</para>
</listitem>
<listitem>
<para><literal>>0</literal> for a buffer with the given maximum size in
@@ -119,8 +119,8 @@
consumption rate specified in units of messages per second. Setting this to <literal
>-1</literal> disables rate limited flow control. The default value is <literal
>-1</literal>.</para>
- <para>Please see the <xref linkend="consumer-rate-limiting-example">consumer rate limiting
- example</xref> for a working example of this.</para>
+ <para>Please see <xref linkend="consumer-rate-limiting-example" /> for a working example
+ of limiting consumer rate.</para>
<section id="flow-control.rate.core.api">
<title>Using Core API</title>
<para>If the JBoss Messaging core API is being used the rate can be set via the <literal
@@ -169,8 +169,8 @@
<section>
<title>Window based flow control</title>
<para>JBoss Messaging clients maintain a buffer of commands that have been sent to the
- server, thus provides a form of flow control. Please see the chapter on <xref
- linkend="command-buffering">command buffering</xref> for more information on
+ server, thus provides a form of flow control. Please see <xref
+ linkend="command-buffering"/> for more information on
this.</para>
</section>
<section>
@@ -182,8 +182,8 @@
consumption rate specified in units of messages per second. Setting this to <literal
>-1</literal> disables rate limited flow control. The default value is <literal
>-1</literal>.</para>
- <para>Please see the <xref linkend="producer-rate-limiting-example">producer rate limiting
- example</xref> for a working example of this.</para>
+ <para>Please see the <xref linkend="producer-rate-limiting-example" />
+ for a working example of limiting producer rate.</para>
<section id="flow-control.producer.rate.core.api">
<title>Using Core API</title>
<para>If the JBoss Messaging core API is being used the rate can be set via the <literal
Modified: trunk/docs/user-manual/en/ha.xml
===================================================================
--- trunk/docs/user-manual/en/ha.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/ha.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -73,7 +73,7 @@
<para>Similarly when a client fails over from a live server <literal>L</literal>to a
backup server <literal>B</literal>, the server <literal>L</literal>becomes invalid
since, from that point on, the data on <literal>L</literal> and <literal>B</literal>
- tmay diverge. After such a failure, at the next available opportunity the <literal
+ may diverge. After such a failure, at the next available opportunity the <literal
>B</literal> server should be taken down, and its <literal>data</literal>
directory copied back to the <literal>L</literal> server. Live and backup servers
can then be restarted. In this release of JBoss Messaging we do not provide any
@@ -121,7 +121,7 @@
a number of different ways. They can be configured explicitly or probably the most
common way of doing this is to use <emphasis>server discovery</emphasis> for the client
to automatically discover the list. For full details on how to configure clients please
- see the section on server discovery [LINK].</para>
+ see <xref linkend="clusters.server-discovery" />.</para>
<para>Sometimes you want a client to failover onto a backup server even if the live server
is just cleanly shutdown rather than having crashed or the connection failed. To
configure this you can set the property <literal>FailoverOnServerShutdown</literal> to
@@ -132,8 +132,8 @@
this property is <literal>false</literal>, this means that by default <emphasis>JBoss
Messaging clients will not failover to a backup server if the live server is simply
shutdown cleanly.</emphasis></para>
- <para>For a fully functional example of automatic failover please see <xref
- linkend="automatic-failover">here</xref>.</para>
+ <para>For a fully functional example of automatic failover, please see <xref
+ linkend="automatic-failover" />.</para>
</section>
<section>
<title>Application-level client failover</title>
@@ -148,15 +148,15 @@
live server.</para>
<para>To implement application-level failover, if you're using JMS then you need to code an
<literal>ExceptionListener</literal> class on the JMS connection. The <literal
- >ExceptionListener</literal> wil be called by JBoss Messaging in the event that
+ >ExceptionListener</literal> will be called by JBoss Messaging in the event that
connection failure is detected. In your <literal>ExceptionListener</literal> you would
close your old JMS connections, potentially look up new connection factory instances
from JNDI and creating new connections. In this case you may well be using HA-JNDI
[link] to ensure that the new connection factory is looked up from a different
server.</para>
- <para>For a working example of application-level failover please see <xref
- linkend="application-level-failover">this</xref> example.</para>
- <para>If you are using the core API, then the procedure is very similar - you would code a
+ <para>For a working example of application-level failover, please see <xref
+ linkend="application-level-failover" />.</para>
+ <para>If you are using the core API, then the procedure is very similar: you would code a
<literal>FailureListener</literal> on your core <literal>ClientSession</literal>
instances.</para>
</section>
Modified: trunk/docs/user-manual/en/interoperability.xml
===================================================================
--- trunk/docs/user-manual/en/interoperability.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/interoperability.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -7,7 +7,7 @@
Stomp clients to communicate with Stomp Brokers. <ulink
url="http://stomp.codehaus.org/StompConnect">StompConnect</ulink> is a server that
can act as a Stomp broker and proxy the Stomp protocol to the standard JMS API.
- Consequenly, using StompConnect it is possible to turn JBM into a Stomp Broker and use
+ Consequently, using StompConnect it is possible to turn JBM into a Stomp Broker and use
any of the available stomp clients. These include clients written in C, C++, c# and .net
etc.</para>
<para>To run StompConnect first start the JBoss Messaging server and make sure that it is
Modified: trunk/docs/user-manual/en/logging.xml
===================================================================
--- trunk/docs/user-manual/en/logging.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/logging.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -1,15 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="logging">
<title>Logging</title>
- <para>JBM uses standard JDK loggin, i.e. JUL, for all its logging. This means we have no
+ <para>JBM uses standard JDK logging, i.e. JUL, for all its logging. This means we have no
dependencies on any third party logging framework. Users can provide their own logging
handler to use or alternatively use one of the handlers provided by JBM. There are 2 of
these a Log4j handler and a JBoss logging handler.</para>
<para>The handlers are configured via the JUL logging.properties file. This default location for
this file is under the <literal>lib</literal> directory found in the Java home directory
- however can be overriden. The standalone JBM server does this and the <literal
- >logging.properties</literal> file can be found under the config directory of the JBM
- installation. </para>
+ however can be overridden. The standalone JBM server does this and the <literal
+ >logging.properties</literal> file can be found under the <literal>config</literal>
+ directory of the JBM installation. </para>
<para>To use the Log4j handler edit the <literal>logging.properties</literal> file and change
the <literal>handlers</literal> property to:</para>
<programlisting>handlers=org.jboss.messaging.integration.logging.Log4jLoggerHandler</programlisting>
Modified: trunk/docs/user-manual/en/message-expiry.xml
===================================================================
--- trunk/docs/user-manual/en/message-expiry.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/message-expiry.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -6,7 +6,7 @@
live</emphasis> is reached.</para>
<para>JBoss Messaging's addresses can be assigned a expiry address so that, when messages are
expired, they are removed from the queue and sent to the expiry address. Many different queues
- cna be bound to an expiry address. These <emphasis>expired</emphasis> messages can later be
+ can be bound to an expiry address. These <emphasis>expired</emphasis> messages can later be
consumed for further inspection.</para>
<section>
<title>Message Expiry</title>
Modified: trunk/docs/user-manual/en/messaging-concepts.xml
===================================================================
--- trunk/docs/user-manual/en/messaging-concepts.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/messaging-concepts.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -21,7 +21,7 @@
messaging systems also support a request-response mode but this is not a primary feature
of messaging systems.</para>
<para>Designing systems to be asynchronous from end-to-end allows you to really take
- advantage of your hardware resources, minimising the amount of threads blocking on IO
+ advantage of your hardware resources, minimizing the amount of threads blocking on IO
operations, and to use your network bandwidth to its full capacity. With an RPC approach
you have to wait for a response for each request you make so are limited by the network
round trip time, or <emphasis role="italic">latency</emphasis> of your network. With an
@@ -40,7 +40,7 @@
</section>
<section>
<title>Messaging styles</title>
- <para>Messaging systems normally support two main styles of asynchronous messaging; <ulink
+ <para>Messaging systems normally support two main styles of asynchronous messaging: <ulink
url="http://en.wikipedia.org/wiki/Message_queue"> message queue</ulink> messaging
(also known as <emphasis role="italic">point-to-point messaging</emphasis>) and <ulink
url="http://en.wikipedia.org/wiki/Publish_subscribe">publish subscribe</ulink>
@@ -72,7 +72,7 @@
processing components. Different messages can be processed by order processors, but
a single order is only processed by one order processor - this ensures orders aren't
processed twice.</para>
- <para>As an order processor receives a message, its fulfils the order, sends order
+ <para>As an order processor receives a message, it fulfills the order, sends order
information to the warehouse system and then updates the order database with the
order details. Once it's done that it acknowledges the message to tell the server
that the order message is done and can be forgotten about. Often the send to the
@@ -158,7 +158,7 @@
normally rich enough to expose all the extra features that most messaging systems
provide.</para>
<para>JBoss Messaging provides its own core client API for clients to use if they wish
- to have access to functionality over and above that accesible via the JMS
+ to have access to functionality over and above that accessible via the JMS
API.</para>
</section>
<section>
@@ -172,7 +172,7 @@
<para>JBoss Messaging can be used by any STOMP client when using the <ulink
url="http://stomp.codehaus.org/StompConnect">StompConnect</ulink> broker which
translates the STOMP protocol to the JMS API.</para>
- <para>JBoss Messaging will be shortly implementing the STOMP protocol on the boker, thus
+ <para>JBoss Messaging will be shortly implementing the STOMP protocol on the broker, thus
avoiding having to use StompConnect.</para>
</section>
<section>
@@ -208,8 +208,7 @@
any special client side code to deal with failure. On failover JBoss Messaging will
automatically fail over your client connections to another server, and your client
sessions can continue as if nothing happened.</para>
- <para>For more information on HA, please see the <xref linkend="ha">HA</xref>
- section.</para>
+ <para>For more information on HA, please see <xref linkend="ha" />.</para>
</section>
<section>
<title>Clusters</title>
@@ -225,8 +224,7 @@
number of consumers on each node, and whether they are ready for messages.</para>
<para>JBoss Messaging also has the ability to automatically redistribute messages between
nodes of a cluster to prevent starvation on any particular node.</para>
- <para>For full details on clustering please the chapter on <xref linkend="clusters"
- >clusters</xref>.</para>
+ <para>For full details on clustering, please see <xref linkend="clusters"/>.</para>
</section>
<section>
<title>Bridges and routing</title>
@@ -241,7 +239,7 @@
configuration. This allows complex routing networks to be set up forwarding or copying
messages from one destination to another, forming a global network of interconnected
brokers.</para>
- <para>See the relevant chapters for more information on <xref linkend="core-bridges"
- >bridges</xref> and <xref linkend="diverts">diverts</xref>.</para>
+ <para>For more information please see <xref linkend="core-bridges"/>
+ and <xref linkend="diverts"/>.</para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/paging.xml
===================================================================
--- trunk/docs/user-manual/en/paging.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/paging.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -88,7 +88,7 @@
mode.</para>
<section>
<title>Configuration</title>
- <para>Address level config is done at the address settings.</para>
+ <para>Address level configuration is done at the address settings.</para>
<programlisting> <address-settings>
<address-setting match="jms.someaddress">
<max-size-bytes>-1</max-size-bytes>
Modified: trunk/docs/user-manual/en/perf-tuning.xml
===================================================================
--- trunk/docs/user-manual/en/perf-tuning.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/perf-tuning.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -72,14 +72,14 @@
messages non transactionally and you need a guarantee that they have reached the
server by the time the call to send() returns, don't set persistent messages to
be sent blocking, instead use asynchronous send acknowledgements to get your
- acknowledgements of send back in a separate stream, see the chapter on <xref
- linkend="send-guarantees">send guarantees</xref> for more information on
+ acknowledgements of send back in a separate stream, see <xref
+ linkend="send-guarantees" /> for more information on
this.</para></listitem>
<listitem>
<para>Use pre-acknowledge mode. With pre-acknowledge mode, messages are acknowledged
<literal>before</literal> they are sent to the client. This reduces the
- amount of acknowledgment traffic on the wire. For more information on this see
- section on <xref linkend="pre-acknowledge">pre acknowledge</xref>.</para>
+ amount of acknowledgment traffic on the wire. For more information on this, see
+ <xref linkend="pre-acknowledge" />.</para>
</listitem>
<listitem>
<para>Disabled security. You may get a small performance boost by disabling security
@@ -96,8 +96,7 @@
>journal-sync-transactional</literal> to <literal>false</literal> in
<literal>jbm-configuration.xml</literal> can give you better transactional
persistent performance at the expense of some possibility of loss of
- transactions on failure. See the chappter on <xref linkend="send-guarantees"
- >send guarantees</xref> for more information.</para>
+ transactions on failure. See <xref linkend="send-guarantees"/> for more information.</para>
</listitem>
<listitem>
<para>Use the core API not JMS. Using the JMS API you will have slightly lower
@@ -115,13 +114,12 @@
than one can fit in a single IP packet. Then you may get a significant
performance boost by enabling Nagle's algorithm. This is done by setting
<literal>jbm.remoting.netty.tcpnodelay</literal> to false with the Netty
- transports. See the chapter on <xref linkend="configuring-transports"
- >configuring transports</xref> for more information on this. </para>
+ transports. See <xref linkend="configuring-transports" /> for more information on this. </para>
</listitem>
<listitem>
<para>TCP buffer sizes. If you have a fast network and fast machines you may get a
performance boost by increasing the TCP send and receive buffer sizes. See the
- chapter on <xref linkend="configuring-transports">configuring transports</xref>
+ <xref linkend="configuring-transports" />
for more information on this. </para>
</listitem>
</itemizedlist>
@@ -140,7 +138,8 @@
</listitem>
<listitem>
<para>Memory settings. Give as much memory as you can to the server. JBoss Messaging
- can run in low memory by using <xref linkend="">paging</xref> but if it can run
+ can run in low memory by using paging (described in <xref linkend="paging" />)
+ but if it can run
with all queues in RAM this will improve performance. The amount of memory you
require will depend on the size and number of your queues and the size and
number of your messages. Use the JVM arguments <literal>-Xms</literal> and
@@ -148,13 +147,13 @@
them to the same high value.</para>
</listitem>
<listitem>
- <para>Aggressive options. Different JVMs provide differents sets of JVM tuning
+ <para>Aggressive options. Different JVMs provide different sets of JVM tuning
parameters, for the Sun Hotspot JVM the full list of options is available <ulink
url="http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp"
>here</ulink>. We recommend at least using <literal
>-XX:+AggressiveOpts</literal> and<literal>
-XX:+UseFastAccessorMethods</literal>. You may get some mileage with the
- other tuning params depending on your OS platform and application usage
+ other tuning parameters depending on your OS platform and application usage
patterns.</para>
</listitem>
</itemizedlist>
Modified: trunk/docs/user-manual/en/persistence.xml
===================================================================
--- trunk/docs/user-manual/en/persistence.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/persistence.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -53,7 +53,7 @@
when AIO informs us that the data has been persisted.</para>
<para>The AIO journal is only available when running Linux kernel 2.6 or later and after
having installed libaio (if it's not already installed). For instructions on how to
- install libaio please see <xref linkend="installing-aio">here</xref>.</para>
+ install libaio please see <xref linkend="installing-aio" />.</para>
</listitem>
</itemizedlist>
<para>The standard JBoss Messaging core server uses two instances of the journal:</para>
@@ -77,12 +77,11 @@
</listitem>
</itemizedlist>
<para>For large messages, JBoss Messaging persists them outside the message journal. This is
- discussed in the chapter on <xref linkend="large-messages">large messages</xref>.</para>
+ discussed in <xref linkend="large-messages" />.</para>
<para>JBoss Messaging also pages messages to disk in low memory situations. This is discussed in
- the chapter on <xref linkend="paging">paging</xref>.</para>
+ <xref linkend="paging" />.</para>
<para>If no persistence is required at all, JBoss Messaging can also be configured not to
- persist any data at all to storage as discussed <xref linkend="persistence.disabled"
- >here</xref>.</para>
+ persist any data at all to storage as discussed in <xref linkend="persistence.enabled" />.</para>
<section id="configuring.bindings.journal">
<title>Configuring the bindings journal</title>
<para>The bindings journal is configured using the following attributes in <literal
@@ -201,7 +200,7 @@
<para>Using aptitude, (e.g. on Ubuntu or Debian system):
<programlisting>sudo apt-get install libaio</programlisting></para>
</section>
- <section id="persistence.disabled">
+ <section id="persistence.enabled">
<title>Configuring JBoss Messaging for Zero Persistence</title>
<para> In some situations, zero persistence is sometimes required for a messaging system.
Configuring JBoss Messaging to perform zero persistence is straightforward. Simply set
Modified: trunk/docs/user-manual/en/project-info.xml
===================================================================
--- trunk/docs/user-manual/en/project-info.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/project-info.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -10,8 +10,8 @@
url="http://www.jboss.org/index.html?module=bb&op=viewforum&f=153">development
forum</ulink></para>
<para>Pop in and chat to us in our <ulink url="irc://irc.freenode.net:6667/jbossmessaging">IRC channel</ulink></para>
- <para>JBoss Messaging svn TRUNK is <ulink url="http://anonsvn.jboss.org/repos/messaging/trunk">here</ulink></para>
+ <para>JBoss Messaging Subversion TRUNK is <ulink url="http://anonsvn.jboss.org/repos/messaging/trunk">here</ulink></para>
<para>All our release tags are <ulink url="http://anonsvn.jboss.org/repos/messaging/tags">here</ulink></para>
- <para>The JBoss Messaging permanent dev team is <ulink url="jbossfox.blogspot.com">Tim Fox</ulink>, Howard Gao, Jeff Mesnil, Clebert
+ <para>The JBoss Messaging permanent dev team is <ulink url="http://jbossfox.blogspot.com">Tim Fox</ulink>, Howard Gao, Jeff Mesnil, Clebert
Suconic, and Andy Taylor</para>
</chapter>
Modified: trunk/docs/user-manual/en/queue-attributes.xml
===================================================================
--- trunk/docs/user-manual/en/queue-attributes.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/queue-attributes.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -23,9 +23,9 @@
queue to different names.</para>
<para>The selector element defines what JMS message selector the predefined queue will have.
Only messages that match the selector will be added to the queue. This is an optional
- element with a default of null when ommitted.</para>
+ element with a default of null when omitted.</para>
<para>The durable element specifies whether the queue will be persisted. This again is
- optional and defaults to true if ommited.</para>
+ optional and defaults to true if omitted.</para>
<para>Secondly a queue can be predefined at a core level in the <literal
>jbm-configuration.xml</literal> file. The following is an example.</para>
<programlisting><queues>
@@ -35,7 +35,7 @@
<durable>true</durable>
</queue>
</queues></programlisting>
- <para>This is very similar to the jms configuration, with 3 real differences which
+ <para>This is very similar to the JMS configuration, with 3 real differences which
are.</para>
<orderedlist>
<listitem>
@@ -49,21 +49,22 @@
<para>There is no entry element.</para>
</listitem>
<listitem>
- <para>The filter uses the <xref linkend="filter-expressions">core filter
- syntax</xref>, <emphasis>not</emphasis> the JMS selector syntax.</para>
+ <para>The filter uses the <emphasis>Core filter syntax</emphasis>
+ (described in <xref linkend="filter-expressions" />),
+ <emphasis>not</emphasis> the JMS selector syntax.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Using the API</title>
- <para>Queues can also be created using the core API or the JMS management API.</para>
- <para>For the core API queues can be created via the <literal
+ <para>Queues can also be created using the core API or the management API.</para>
+ <para>For the core API, queues can be created via the <literal
>org.jboss.messaging.core.client.ClientSession</literal> interface. There are
multiple <literal>createQueue</literal> methods that support setting all of the
previously mentioned attributes. There is one extra attribute that can be set via this
API which is <literal>temporary</literal>. setting this to true means that the queue
will be deleted once the session is disconnected.</para>
- <para>Take a look at the <xref linkend="management">management section</xref> for the API
+ <para>Take a look at <xref linkend="management" /> for a description of the management API
for creating queues.</para>
</section>
<section id="queue-attributes.address-settings">
Modified: trunk/docs/user-manual/en/security.xml
===================================================================
--- trunk/docs/user-manual/en/security.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/security.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -11,7 +11,7 @@
<title>Role based security for addresses</title>
<para>JBoss Messaging contains a flexible role-based security model for applying security to
queues, based on their addresses.</para>
- <para>As explained <xref linkend="using-core">here</xref> JBoss Messaging core consists
+ <para>As explained in <xref linkend="using-core" />, JBoss Messaging core consists
mainly of sets of queues bound to addresses. A message is sent to an address and the
server looks up the set of queues that are bound to that address, the server then routes
the message to those set of queues.</para>
@@ -68,8 +68,8 @@
</programlisting>
<para>The '<literal>#</literal>' character signifies "any sequence of words". Words are
delimited by the '<literal>.</literal>' character. For a full description of the
- wildcard syntax please see the chapter on <xref linkend="wildcard-syntax">wildcard
- syntax</xref>.. The above security block applies to any address that starts with the
+ wildcard syntax please see <xref linkend="wildcard-syntax"/>.
+ The above security block applies to any address that starts with the
string "globalqueues.europe.":</para>
<para>Only users who have the <literal>admin</literal> role can create or delete durable
queues bound to an address that starts with the string "globalqueues.europe."</para>
@@ -84,8 +84,8 @@
<para>The mapping between a user and what roles they have is handled by the security
manager. JBoss Messaging ships with a user manager that reads user credentials from a
file on disk, and can also plug into JAAS or JBoss Application Server security.</para>
- <para>For more information on configuring the security manager please see <xref
- linkend="change-security-manager">this</xref> section.</para>
+ <para>For more information on configuring the security manager, please see <xref
+ linkend="change-security-manager" />.</para>
<para>There can be zero or more <literal>security-setting</literal> elements in each xml
file. Where more than one match applies to a set of addresses the <emphasis>more
specific</emphasis> match takes precedence.</para>
@@ -119,8 +119,8 @@
<para>When messaging clients are connected to servers, or servers are connected to other
servers (e.g. via bridges) over an untrusted network then JBoss Messaging allows that
traffic to be encrypted using the Secure Sockets Layer (SSL) transport.</para>
- <para>For more information on configuring the SSL transport please see the chapter on <xref
- linkend="configuring-transports">configuring transports</xref>.</para>
+ <para>For more information on configuring the SSL transport, please see <xref
+ linkend="configuring-transports" />.</para>
</section>
<section>
<title>Basic user credentials</title>
@@ -252,7 +252,7 @@
these actions as a user with a role that has <literal>admin</literal> permissions on the
management addresses.</para>
<para>This password should always be changed from its default after installation. Please see
- the <xref linkend="management">management chapter</xref> for instructions on how to do
+ <xref linkend="management" /> for instructions on how to do
this.</para>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/send-guarantees.xml
===================================================================
--- trunk/docs/user-manual/en/send-guarantees.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/send-guarantees.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -51,8 +51,8 @@
your network, rather than the bandwidth of your network. For better performance we
recommend either batching many messages sends together in a transaction since with a
transactional session, only the commit / rollback blocks not every send, or, using JBoss
- Messaging's advanced <xref linkend="asynchronous-send-acknowledgements">asynchronous
- send acknowledgements</xref> feature.</para>
+ Messaging's advanced <emphasis>asynchronous send acknowledgements feature</emphasis>
+ described in <xref linkend="asynchronous-send-acknowledgements" />.</para>
<para>If you are using JMS and you're using the JMS service on the server to load your JMS
connection factory instances into JNDI then these parameters can be configured in
<literal>jbm-jms.xml</literal> using the elements <literal
@@ -87,7 +87,7 @@
<section id="asynchronous-send-acknowledgements">
<title>Asynchronous Send Acknowledgements</title>
<para>If you are using a non transacted session but want a guarantee that every message sent
- to the server has reached it, then, as discussed in section <xref
+ to the server has reached it, then, as discussed in <xref
linkend="non-transactional-sends"/>, you can configure JBoss Messaging to block the
call to send until the server has received the message, persisted it and sent back a
response. This works well but has a severe performance penalty - each call to send needs
@@ -124,8 +124,8 @@
informed at the client side by JBoss Messaging calling your handler's <literal
>sendAcknowledged(ClientMessage message)</literal> method, passing in a
reference to the message that was sent.</para>
- <para>Please see the <xref linkend="asynchronous-send-acknowledgements-example">send
- acknowledgements exampl</xref>e for a full working example.</para>
+ <para>Please see <xref linkend="asynchronous-send-acknowledgements-example" />
+ for a full working example.</para>
</section>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/thread-pooling.xml
===================================================================
--- trunk/docs/user-manual/en/thread-pooling.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/thread-pooling.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -54,8 +54,8 @@
<para>A single thread is also used on the server side to scan for expired messages in
queues. We cannot use either of the thread pools for this since this thread needs to
run at its own configurable priority.</para>
- <para>For more information on configuring the reaper, please see the section on <xref
- linkend="message-expiry">message expiry</xref>.</para>
+ <para>For more information on configuring the reaper, please see <xref
+ linkend="message-expiry"/>.</para>
</section>
<section>
<title>Asychronous IO</title>
@@ -64,7 +64,7 @@
<para>The thread poller is used by the native layer to receive and dispatch events. You
will find it on a thread dump with the prefix JBM-AIO-poller-pool. JBoss Messaging
uses one poller per opened file on the journal. (there is usually one) and they are
- aways distributed through a pool.</para>
+ always distributed through a pool.</para>
<para>The writing thread is a single thread used to invoke libaio. We do that to avoid
context switching on libaio what would cause performance issues. You will find this
thread on a thread dump with the prefix JBM-AIO-writer-pool.</para>
Modified: trunk/docs/user-manual/en/using-core.xml
===================================================================
--- trunk/docs/user-manual/en/using-core.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/using-core.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -11,8 +11,8 @@
<para>Some of the core messaging concepts are similar to JMS concepts, but core messaging
concepts differ in some ways. In general the core messaging API is simpler than the JMS
API, since we remove distinctions between queues, topics and subscriptions. We'll
- discuss each of the major core messaging concepts in turn, but for to see the API in
- detail please consult the javadoc.</para>
+ discuss each of the major core messaging concepts in turn, but to see the API in
+ detail, please consult the Javadoc.</para>
<section>
<title>Message</title>
<para>A message is the unit of data which is sent between clients and servers.</para>
@@ -27,7 +27,7 @@
<para>Messages can be either durable or non durable. Durable messages in a durable queue
will survive a server crash or restart. Non durable messages will never survive a
server crash or restart.</para>
- <para>Messages can be specified with a priority value betwen 0 and 9. 0 represents the
+ <para>Messages can be specified with a priority value between 0 and 9. 0 represents the
highest priority and 9 represents the lowest. JBoss Messaging will attempt to
deliver higher priority messages before lower priority ones.</para>
<para>Messages can be specified with an optional expiry time. JBoss Messaging will not
Modified: trunk/docs/user-manual/en/using-jms.xml
===================================================================
--- trunk/docs/user-manual/en/using-jms.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/using-jms.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -10,7 +10,7 @@
<para>JBoss Messaging also ships with a wide range of examples, many of which demonstrate JMS
API usage. A good place to start would be to play around with the simple JMS Queue and Topic
example, but we also provide examples for many other parts of the JMS API. A full
- description of the examples is available <xref linkend="examples">here</xref>.</para>
+ description of the examples is available in <xref linkend="examples" />.</para>
<para>In this section we'll go through the main steps in configuring the server for JMS and
creating a simple JMS program. We'll also show how to configure and use JNDI, and also how
to use JMS with JBoss Messaging without using any JNDI.</para>
@@ -24,8 +24,8 @@
single <literal>MessageConsumer</literal> consuming the order message from the
queue.</para>
<para>The queue will be a <literal>durable</literal> queue, i.e. it will survive a server
- restart or crash. We also want to predeploy the queue, i.e. specifiy the queue in the
- server JMS config so it's created automatically without us having to explicitly create
+ restart or crash. We also want to predeploy the queue, i.e. specify the queue in the
+ server JMS configuration so it's created automatically without us having to explicitly create
it from the client.</para>
</section>
<section id="using-jms.server.configuration">
@@ -38,7 +38,7 @@
configuration parameters. In most cases the defaults will be acceptable.</para>
<para>We'll deploy a single JMS Queue and a single JMS Connection Factory instance on the
server for this example but there are no limits to the number of Queues, Topics and
- Connection Factory instances you can deploy from the file. Here's our config:</para>
+ Connection Factory instances you can deploy from the file. Here's our configuration:</para>
<programlisting>
<configuration xmlns="urn:jboss:messaging"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -145,13 +145,12 @@
<para>With JBoss Messaging you can do exactly that. JBoss Messaging supports the direct
instantiation of JMS Queue, Topic and Connection Factory instances, so you don't have to
use JNDI at all.</para>
- <para>For a full working example of direct instantiation please see the JMS <xref
- linkend="examples">examples</xref>.</para>
+ <para>For a full working example of direct instantiation please see the JMS examples in <xref
+ linkend="examples" />.</para>
<para>Here's our simple example, rewritten to not use JNDI at all:</para>
<para>We create the JMS ConnectionFactory object directly, note we need to provide
- connection params and specify which transport we are using, for more information on
- connectors please see the section on <xref linkend="configuring-transports">configuring
- transports</xref>.</para>
+ connection parameters and specify which transport we are using, for more information on
+ connectors please see <xref linkend="configuring-transports" />.</para>
<programlisting>
TransportConfiguration transportConfiguration =
new TransportConfiguration(NettyConnectorFactory.class.getName());
Modified: trunk/docs/user-manual/en/using-server.xml
===================================================================
--- trunk/docs/user-manual/en/using-server.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/using-server.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -76,8 +76,7 @@
<para>JBoss Messaging uses JDK logging to minimise dependencies on other logging systems.
JDK logging can then be configured to delegate to some other framework, e.g. log4j if
that's what you prefer.</para>
- <para>For more information on configuring logging, please see the section <link
- linkend="logging">configuring logging</link></para>
+ <para>For more information on configuring logging, please see <xref linkend="logging" />.</para>
</section>
<section id="using-server.configuration">
<title>Configuration files</title>
@@ -91,13 +90,13 @@
dependencies to enforce between them. Remember that JBoss Messaging is just a
set of POJOs. In the stand-alone server, it's the JBoss Microcontainer which
instantiates these POJOs and enforces dependencies between them and other beans.
- Please see the <xref linkend="usingserver.mainconfig"/> section for more
+ Please see <xref linkend="usingserver.mainconfig"/> for more
information on this file.</para>
</listitem>
<listitem>
<para><literal>jbm-configuration.xml</literal>. This is the main JBoss Messaging
- configuration file. All the parameters in this file are described <xref
- linkend="configuration-index">here</xref>.</para>
+ configuration file. All the parameters in this file are described in <xref
+ linkend="configuration-index" />.</para>
</listitem>
<listitem>
<para><literal>jbm-queues.xml</literal>. This file contains pre-defined queues,
@@ -112,23 +111,23 @@
</listitem>
<listitem>
<para><literal>jbm-users.xml</literal> JBoss Messaging ships with a security manager
- impementation which obtains user credentials from the <literal
+ implementation which obtains user credentials from the <literal
>jbm-users.xml</literal> file. This file contains user, password and role
- information. For more information on security please see the chapter on <xref
- linkend="security">security</xref>.</para>
+ information. For more information on security ,please see <xref
+ linkend="security"/>.</para>
</listitem>
<listitem>
<para><literal>jbm-jms.xml</literal> The distro configuration by default includes a
server side JMS service which mainly deploys JMS Queues, Topics and
ConnectionFactorys from this file into JNDI. If you're not using JMS, or you
don't need to deploy JMS objects on the server side, then you don't need this
- file. For more information on using JMS, please see the <xref
- linkend="using-jms">using JMS</xref> chapter.</para>
+ file. For more information on using JMS, please see <xref
+ linkend="using-jms" />.</para>
</listitem>
<listitem>
<para><literal>logging.properties</literal> This is used to configure the logging
- handlers used by the Java logger. For more information on configuring logging
- please see <xref linkend="logging">this chapter</xref>.</para>
+ handlers used by the Java logger. For more information on configuring logging,
+ please see <xref linkend="logging"/>.</para>
</listitem>
<listitem>
<para><literal>log4j.xml</literal> This is the Log4j configuration if the Log4j
@@ -140,9 +139,9 @@
>jbm-configuration.xml</literal> configuration when set to false mans that the
other configuration files are not loaded. This is true by default.</para>
</note>
- <para>It is also possible to use system property substitution in all the config files. by
+ <para>It is also possible to use system property substitution in all the configuration files. by
replacing a value with the name of a system property. Here is an example of this with a
- connector config:</para>
+ connector configuration:</para>
<programlisting><connector name="netty">
<factory-class>org.jboss.messaging.integration.transports.netty.NettyConnectorFactory</factory-class>
<param key="jbm.remoting.netty.host" value="${jbm.remoting.netty.host:localhost}" type="String"/>
@@ -272,7 +271,7 @@
instances from <literal>jbm-jms.xml</literal> files on the disk. It also
provides a simple management API for manipulating JMS Objects. On the whole it
just translates and delegates its work to the core server. If you don't need to
- deploy JMS Queues, Topics and ConnectionFactorys from server side config and
+ deploy JMS Queues, Topics and ConnectionFactorys from server side configuration and
don't require the JMS management interface this can be disabled.</para>
</listitem>
</itemizedlist>
Modified: trunk/docs/user-manual/en/wildcard-routing.xml
===================================================================
--- trunk/docs/user-manual/en/wildcard-routing.xml 2009-05-26 08:37:49 UTC (rev 7010)
+++ trunk/docs/user-manual/en/wildcard-routing.xml 2009-05-26 09:11:46 UTC (rev 7011)
@@ -9,12 +9,12 @@
sent to a <emphasis>hierarchy</emphasis> of addresses, rather than the consumer having to
specify a specific address.</para>
<note>
- <para>In JMS terminoligy this allows "topic hierarchies" to be created.</para>
+ <para>In JMS terminology this allows "topic hierarchies" to be created.</para>
</note>
<para>To enable this functionality set the property <literal>wild-card-routing-enabled</literal>
in the <literal>jbm-configuration.xml</literal> file to <literal>true</literal>. This is
<literal>true</literal> by default.</para>
- <para>For more information on the wild card syntax take a look at the <link
- linkend="wildcard-syntax">wildcard syntax</link> chapter, also see the <xref
- linkend="topic-hierarchy-example">topic hierarchy example</xref>.</para>
+ <para>For more information on the wild card syntax take a look at <xref
+ linkend="wildcard-syntax" /> chapter, also see <xref
+ linkend="topic-hierarchy-example" />.</para>
</chapter>
More information about the jboss-cvs-commits
mailing list