[jboss-cvs] JBoss Messaging SVN: r6994 - trunk/docs/user-manual/en.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri May 22 05:49:41 EDT 2009
Author: ataylor
Date: 2009-05-22 05:49:41 -0400 (Fri, 22 May 2009)
New Revision: 6994
Added:
trunk/docs/user-manual/en/wildcard-routing.xml
Modified:
trunk/docs/user-manual/en/clusters.xml
trunk/docs/user-manual/en/configuration-index.xml
trunk/docs/user-manual/en/master.xml
trunk/docs/user-manual/en/security.xml
trunk/docs/user-manual/en/using-server.xml
Log:
more proof reading and new chapter
Modified: trunk/docs/user-manual/en/clusters.xml
===================================================================
--- trunk/docs/user-manual/en/clusters.xml 2009-05-22 09:17:59 UTC (rev 6993)
+++ trunk/docs/user-manual/en/clusters.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -8,7 +8,9 @@
<para>JBoss Messaging clusters allow groups of JBoss Messaging servers to be grouped
together in order to share message processing load. Each active node in the cluster is
an active JBoss Messaging server which manages its own messages and handles its own
- connections.</para>
+ connections. A server must be configured to be clustered, you will need to set the
+ <literal>clustered</literal> element in the <literal>jbm-configuration.xml</literal>
+ configuration file to true, this is false by 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 core
@@ -57,12 +59,12 @@
<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>
- <para>Broadcast groups are defined in the server configuration file
- <literal>jbm-configuration.xml</literal>. There can be many broadcast groups per
- JBoss Messaging server. All broadcast groups must be defined in a
- <literal>broadcast-groups</literal> element.</para>
- <para>Let's take a look at an example broadcast group from
- <literal>jbm-configuration.xml</literal>:</para>
+ <para>Broadcast groups are defined in the server configuration file <literal
+ >jbm-configuration.xml</literal>. There can be many broadcast groups per JBoss
+ Messaging server. All broadcast groups must be defined in a <literal
+ >broadcast-groups</literal> element.</para>
+ <para>Let's take a look at an example broadcast group from <literal
+ >jbm-configuration.xml</literal>:</para>
<programlisting><broadcast-groups>
<broadcast-group name="my-broadcast-group">
<local-bind-port>54321</local-bind-port>
@@ -114,9 +116,9 @@
optional backup connector that will be broadcast. Please see section [LINK]
for more information on connectors. The connector to be broadcast 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. The
- <literal>backup-connector</literal> attribute is optional.</para>
+ connector to be broadcast is specified by the <literal
+ >backup-connector</literal> attribute. The <literal
+ >backup-connector</literal> attribute is optional.</para>
</listitem>
</itemizedlist>
</section>
@@ -177,10 +179,10 @@
<para><literal>refresh-timeout</literal>. This is the period the discovery group
waits after receiving the last broadcast from a particular server before
removing that servers connector pair entry from its list. You would normally
- set this to a value significantly higher than the
- <literal>broadcast-period</literal> on the broadcast group otherwise
- servers might intermittently disappear from the list even though they are
- still broadcasting due to slight differences in timing. This parameter is
+ set this to a value significantly higher than the <literal
+ >broadcast-period</literal> on the broadcast group otherwise servers
+ might intermittently disappear from the list even though they are still
+ broadcasting due to slight differences in timing. This parameter is
optional, the default value is <literal>10000</literal> milliseconds (10
seconds).</para>
</listitem>
@@ -233,13 +235,13 @@
factory is used immediately after creation then it may not have had enough time
to received broadcasts from all the nodes in the cluster. On first usage, the
connection factory will make sure it waits this long since creation before
- creating the first connection. The default value for this parameter is
- <literal>2000</literal> milliseconds.</para>
+ creating the first connection. The default value for this parameter is <literal
+ >2000</literal> milliseconds.</para>
</section>
<section>
<title>Configuring client discovery using Core</title>
- <para>If you're using the core API to directly instantiate
- <literal>ClientSessionFactory</literal> instances, then you can specify the
+ <para>If you're using the core API to directly instantiate <literal
+ >ClientSessionFactory</literal> instances, then you can specify the
discovery group parameters directly when creating the session factory. Here's an
example:final String groupAddress = "231.7.7.7"; final int groupPort = 9876;
SessionFactory factory = new ClientSessionFactoryImpl(groupAddress, groupPort);
@@ -253,8 +255,8 @@
is used immediately after creation then it may not have had enough time to
received broadcasts from all the nodes in the cluster. On first usage, the
session factory will make sure it waits this long since creation before creating
- the first session. The default value for this parameter is
- <literal>2000</literal> milliseconds.</para>
+ the first session. The default value for this parameter is <literal
+ >2000</literal> milliseconds.</para>
</section>
</section>
</section>
@@ -288,10 +290,10 @@
<title>Configuring Cluster Connections</title>
<para>Cluster Connections group servers into clusters so that messages can be load
balanced between the nodes of the cluster. Let's take a look at a typical cluster
- connection. Cluster connections are always defined in
- <literal>jbm-configuration.xml</literal> inside a
- <literal>cluster-connection</literal> element. There can be zero or more cluster
- connections defined per JBoss Messaging server.</para>
+ connection. Cluster connections are always defined in <literal
+ >jbm-configuration.xml</literal> inside a <literal>cluster-connection</literal>
+ element. There can be zero or more cluster connections defined per JBoss Messaging
+ server.</para>
<programlisting>
<cluster-connections>
<cluster-connection name="my-cluster">
@@ -346,11 +348,11 @@
of the bridge crashes and then recovers, messages might be resent from the
source node. By enabling duplicate detection any duplicate messages will be
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 see chapter [LINK].</para>
- <para>This parameter is optional and has a default value of
- <literal>true</literal>.</para>
+ <para>This parameter has the same meaning as <literal
+ >use-duplicate-detection</literal> on a bridge. For more information on
+ duplicate detection please see chapter [LINK].</para>
+ <para>This parameter is optional and has a default value of <literal
+ >true</literal>.</para>
</listitem>
<listitem>
<para><literal>forward-when-no-consumers</literal>. This parameter determines
@@ -369,8 +371,8 @@
are being forwarded has queues which have consumers, and if those consumers
have message filters (selectors) at least one of those selectors must match
the message.</para>
- <para>This parameter is optional, the default value is
- <literal>false</literal>.</para>
+ <para>This parameter is optional, the default value is <literal
+ >false</literal>.</para>
</listitem>
<listitem>
<para><literal>max-hops</literal>. When a cluster connection decides the set of
@@ -416,11 +418,11 @@
<para>Random. With this policy each node is chosen randomly.</para>
</listitem>
</itemizedlist>
- <para>You can also implement your own policy by implementing the interface
- <literal>org.jboss.messaging.core.client.ConnectionLoadBalancingPolicy</literal></para>
+ <para>You can also implement your own policy by implementing the interface <literal
+ >org.jboss.messaging.core.client.ConnectionLoadBalancingPolicy</literal></para>
<para>Specifying which load balancing policy to use differs whether you are using JMS or the
- core API. If you don't specify a policy then the default will be used which is
- <literal>org.jboss.messaging.core.client.impl.RoundRobinConnectionLoadBalancingPolicy</literal>.</para>
+ core API. If you don't specify a policy then the default will be used which is <literal
+ >org.jboss.messaging.core.client.impl.RoundRobinConnectionLoadBalancingPolicy</literal>.</para>
<para>If you're using JMS, and you're using JNDI on the server to put your JMS connection
factories into JNDI, then you can specify the load balancing policy directly in the
<literal>jbm-jms.xml</literal> configuration file on the server as follows:
@@ -438,8 +440,8 @@
above example would deploy a JMS connection factory that uses the random connection load
balancing policy. </para>
<para>If you're using JMS but you're instantiating your connection factory directly on the
- client side then you can set the load balancing policy using the setter on the
- <literal>JBossConnectionFactory</literal> before using it:
+ client side then you can set the load balancing policy using the setter on the <literal
+ >JBossConnectionFactory</literal> before using it:
<programlisting>
ConnectionFactory jmsConnectionFactory = new JBossConnectionFactory(...);
jmsConnectionFactory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
@@ -477,8 +479,8 @@
<title>Specifying List of Servers using JMS</title>
<para>If you're using JMS, and you're using the JMS Service to load your JMS
connection factory instances directly into JNDI on the server, then you can
- specify the list of servers in the server side configuration file
- <literal>jbm-jms.xml</literal>. Let's take a look at an example:</para>
+ specify the list of servers in the server side configuration file <literal
+ >jbm-jms.xml</literal>. Let's take a look at an example:</para>
<programlisting><connection-factory name="ConnectionFactory">
<connector-ref connector-name="my-connector1"
backup-connector-name="my-backup-connector1"/>
@@ -492,14 +494,14 @@
</connection-factory></programlisting>
<para>The <literal>connection-factory</literal> element can contain zero or more
<literal>connector-ref</literal> elements, each one of which specifies a
- <literal>connector-name</literal> attribute and an optional
- <literal>backup-connector-name</literal> attribute. The
- <literal>connector-name</literal> attribute references a connector defined
- in <literal>jbm-configuration.xml</literal> which will be used as a live
+ <literal>connector-name</literal> attribute and an optional <literal
+ >backup-connector-name</literal> attribute. The <literal
+ >connector-name</literal> attribute references a connector defined in
+ <literal>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>
+ specified it also references a connector defined in <literal
+ >jbm-configuration.xml</literal>. For more information on connectors please
+ see chapter [LINK].</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>
@@ -521,11 +523,11 @@
Connection jmsConnection1 = jmsConnectionFactory.createConnection();
Connection jmsConnection2 = jmsConnectionFactory.createConnection();</programlisting></para>
- <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 connectors [LINK].</para>
+ <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 connectors [LINK].</para>
<para>A <literal>JBossConnectionFactory</literal> instance is then created passing
the list of servers in the constructor. Any connections subsequently created by
this factory will create connections according to the client connection load
@@ -551,11 +553,11 @@
ClientSession sesison1 = factory.createClientSession(...);
ClientSession session2 = factory.createClientSession(...);</programlisting>
- <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 connectors [LINK].</para>
+ <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 connectors [LINK].</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
@@ -582,11 +584,11 @@
</cluster-connections></programlisting>
<para>The <literal>cluster-connection</literal> element can contain zero or more
<literal>connector-ref</literal> elements, each one of which specifies a
- <literal>connector-name</literal> attribute and an optional
- <literal>backup-connector-name</literal> attribute. The
- <literal>connector-name</literal> attribute references a connector defined in
- <literal>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
+ <literal>connector-name</literal> attribute and an optional <literal
+ >backup-connector-name</literal> attribute. The <literal
+ >connector-name</literal> attribute references a connector defined in <literal
+ >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>
</section>
@@ -594,14 +596,13 @@
<section>
<title>Message Redistribution</title>
<para>Another important part of clustering is message redistribution. Earlier we learned how
- server side message load balancing round robins messages across the cluster. If
- <literal>forward-when-no-consumers</literal> is false, then messages won't be
- forwarded to nodes which don't have matching consumers, this is great and ensures that
- messages don't arrive on a queue which has no consumers to consume them, however there
- is a situation it doesn't solve: What happens if the consumers on a queue close after
- the messages have been sent to the node? If there are no consumers on the queue the
- message won't get consumed and we have a <emphasis>starvation</emphasis>
- situation.</para>
+ server side message load balancing round robins messages across the cluster. If <literal
+ >forward-when-no-consumers</literal> is false, then messages won't be forwarded to
+ nodes which don't have matching consumers, this is great and ensures that messages don't
+ arrive on a queue which has no consumers to consume them, however there is a situation
+ it doesn't solve: What happens if the consumers on a queue close after the messages have
+ been sent to the node? If there are no consumers on the queue the message won't get
+ consumed and we have a <emphasis>starvation</emphasis> situation.</para>
<para>This is where message redistribution comes in. With message redistribution JBoss
Messaging can be configured to automatically <emphasis>redistribute</emphasis> messages
from queues which have no consumers back to other nodes in the cluster which do have
@@ -620,11 +621,11 @@
<redistribution-delay>0</redistribution-delay>
</address-setting>
</address-settings></programlisting>
- <para>The above <literal>address-settings</literal> block would set a
- <literal>redistribution-delay</literal> of <literal>0</literal> for any queue which
- is bound to an address that starts with "jms.". All JMS queues and topic subscriptions
- are bound 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 above <literal>address-settings</literal> block would set a <literal
+ >redistribution-delay</literal> of <literal>0</literal> for any queue which is bound
+ to an address that starts with "jms.". All JMS queues and topic subscriptions are bound
+ 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>
@@ -632,8 +633,8 @@
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
means the messages will be immediately redistributed. A value of <literal>-1</literal>
- signifies that messages will never be redistributed. The default value is
- <literal>-1</literal>.</para>
+ signifies that messages will never be redistributed. The default value is <literal
+ >-1</literal>.</para>
<para>It often makes sense to introduce a delay before redistributing as it's a common case
that a consumer closes but another one quickly is created on the same queue, in such a
case you probably don't want to redistribute immediately since the new consumer will
@@ -680,12 +681,12 @@
connects to node B, and node B would define a cluster connection that connects to
node C. In this case we only want cluster connections in one direction since we're
only moving messages from node A->B->C and never from C->B->A.</para>
- <para>For this topology we would set <literal>max-hops</literal> to
- <literal>2</literal>. With a value of <literal>2</literal> the knowledge of what
- queues and consumers that exist on node C would be propagated from node C to node B
- to node A. Node A would then know to distribute messages to node B when they arrive,
- even though node B has no consumers itself, it would know that a further hop away is
- node C which does have consumers.</para>
+ <para>For this topology we would set <literal>max-hops</literal> to <literal
+ >2</literal>. With a value of <literal>2</literal> the knowledge of what queues and
+ consumers that exist on node C would be propagated from node C to node B to node A.
+ Node A would then know to distribute messages to node B when they arrive, even
+ though node B has no consumers itself, it would know that a further hop away is node
+ C which does have consumers.</para>
</section>
</section>
</chapter>
Modified: trunk/docs/user-manual/en/configuration-index.xml
===================================================================
--- trunk/docs/user-manual/en/configuration-index.xml 2009-05-22 09:17:59 UTC (rev 6993)
+++ trunk/docs/user-manual/en/configuration-index.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -25,13 +25,14 @@
</thead>
<tbody>
<row>
- <entry>clustered</entry>
+ <entry><link linkend="clusters">clustered</link></entry>
<entry>Boolean</entry>
<entry>True means that the server is clustered</entry>
<entry>false</entry>
</row>
<row>
- <entry>file-deployment-enabled</entry>
+ <entry><link linkend="using-server.configuration"
+ >file-deployment-enabled</link></entry>
<entry>Boolean</entry>
<entry>True means that the server will load configuration from the
configuration files</entry>
@@ -62,25 +63,26 @@
<entry>-1</entry>
</row>
<row>
- <entry>security-enabled</entry>
+ <entry><link linkend="security">security-enabled</link></entry>
<entry>Boolean</entry>
<entry>True means that security is enabled</entry>
<entry>true</entry>
</row>
<row>
- <entry>security-invalidation-interval</entry>
+ <entry><link linkend="security"
+ >security-invalidation-interval</link></entry>
<entry>Long</entry>
<entry>How long, in milli seconds, to wait before invalidating the
security cache</entry>
<entry>10000</entry>
</row>
<row>
- <entry>wild-card-routing-enabled</entry>
+ <entry><link linkend="wildcard-routing"
+ >wild-card-routing-enabled</link></entry>
<entry>Boolean</entry>
<entry>True means that the server supports wild card routing</entry>
<entry>true</entry>
</row>
-
<row>
<entry><link linkend="management.core.configuration"
>management-address</link></entry>
@@ -142,7 +144,8 @@
<entry>10</entry>
</row>
<row>
- <entry><link linkend="dead.connections">connection-scan-period</link></entry>
+ <entry><link linkend="dead.connections"
+ >connection-scan-period</link></entry>
<entry>Long</entry>
<entry>How often, in milli seconds, to scan for failed connections on
the server </entry>
@@ -469,7 +472,8 @@
<row>
<entry>bridges.forwarding-address</entry>
<entry>String</entry>
- <entry>Address to forward to. If ommitted original destination is used.</entry>
+ <entry>Address to forward to. If ommitted original destination is
+ used.</entry>
<entry>null</entry>
</row>
<row>
@@ -505,13 +509,15 @@
<row>
<entry>bridges.failover-on-server-shutdown</entry>
<entry>Boolean</entry>
- <entry>Should failover be prompted if target server is cleanly shutdown?</entry>
+ <entry>Should failover be prompted if target server is cleanly
+ shutdown?</entry>
<entry>false</entry>
</row>
<row>
<entry>bridges.use-duplicate-detection</entry>
<entry>Boolean</entry>
- <entry>Should duplicate detection headers be inserted in forwarded messages?</entry>
+ <entry>Should duplicate detection headers be inserted in forwarded
+ messages?</entry>
<entry>true</entry>
</row>
<row>
@@ -524,7 +530,7 @@
<entry>bridges.connector-ref.connector-name (attribute)</entry>
<entry>String</entry>
<entry>Name of connector to use for live connection</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>bridges.connector-ref.backup-connector-name (attribute)</entry>
@@ -550,11 +556,12 @@
<entry>String</entry>
<entry>Name of address this cluster connection applies to</entry>
<entry/>
- </row>
+ </row>
<row>
<entry>cluster-connections.forward-when-no-consumers</entry>
<entry>Boolean</entry>
- <entry>Should messages be load balanced if there are no matching consumers on target?</entry>
+ <entry>Should messages be load balanced if there are no matching
+ consumers on target?</entry>
<entry>false</entry>
</row>
<row>
@@ -568,11 +575,12 @@
<entry>Long</entry>
<entry>Period in ms between successive retries</entry>
<entry>2000 ms</entry>
- </row>
+ </row>
<row>
<entry>cluster-connections.use-duplicate-detection</entry>
<entry>Boolean</entry>
- <entry>Should duplicate detection headers be inserted in forwarded messages?</entry>
+ <entry>Should duplicate detection headers be inserted in forwarded
+ messages?</entry>
<entry>true</entry>
</row>
<row>
@@ -582,13 +590,15 @@
<entry>null</entry>
</row>
<row>
- <entry>cluster-connections.connector-ref.connector-name (attribute)</entry>
+ <entry>cluster-connections.connector-ref.connector-name
+ (attribute)</entry>
<entry>String</entry>
<entry>Name of connector to use for live connection</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
- <entry>cluster-connections.connector-ref.backup-connector-name (attribute)</entry>
+ <entry>cluster-connections.connector-ref.backup-connector-name
+ (attribute)</entry>
<entry>String</entry>
<entry>Optional name of connector to use for backup connection</entry>
<entry>null</entry>
@@ -612,7 +622,8 @@
</section>
<section>
<title>jbm-jms.xml</title>
- <para>This is the configuration file used by the server side JMS service to load JMS Queues, Topics and Connection Factories</para>
+ <para>This is the configuration file used by the server side JMS service to load JMS
+ Queues, Topics and Connection Factories</para>
<table frame="topbot" border="2">
<title>JMS Server Configuration</title>
<tgroup cols="4">
@@ -634,7 +645,7 @@
>connection-factory</link></entry>
<entry>ConnectionFactory</entry>
<entry>A list of connection factories to create and add to JNDI</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>connection-factory.client-id</entry>
@@ -645,11 +656,13 @@
<row>
<entry>connection-factory.ping-period</entry>
<entry>Long</entry>
- <entry>The period between ping packets being sent from client to server.</entry>
+ <entry>The period between ping packets being sent from client to
+ server.</entry>
<entry>5000 ms</entry>
</row>
<row>
- <entry><link linkend="dead.connections">connection-factory.connection-ttl</link></entry>
+ <entry><link linkend="dead.connections"
+ >connection-factory.connection-ttl</link></entry>
<entry>long</entry>
<entry>The time to live for connections</entry>
<entry>5 * 60000 ms</entry>
@@ -662,28 +675,28 @@
</row>
<row>
<entry><link linkend="connection-ttl.session.multiplexing"
- >connection-factory.max-connections</link></entry>
+ >connection-factory.max-connections</link></entry>
<entry>int</entry>
<entry>The max number of connections per factory</entry>
<entry>8</entry>
</row>
<row>
<entry><link linkend="large-messages.core.config"
- >connection-factory.min-large-message-size</link></entry>
+ >connection-factory.min-large-message-size</link></entry>
<entry>int</entry>
<entry>The size, in bytes, before a message is treated as large </entry>
<entry>100 * 1024</entry>
</row>
<row>
<entry><link linkend="flow-control.core.api"
- >connection-factory.consumer-window-size</link></entry>
+ >connection-factory.consumer-window-size</link></entry>
<entry>int</entry>
<entry>The window size, in bytes, for consumer flow control</entry>
<entry>1024 * 1024</entry>
</row>
<row>
<entry><link linkend="flow-control.rate.core.api"
- >connection-factory.consumer-max-rate</link></entry>
+ >connection-factory.consumer-max-rate</link></entry>
<entry>int</entry>
<entry>The fastest rate a consumer may consume messages per
second</entry>
@@ -697,31 +710,31 @@
</row>
<row>
<entry><link linkend="flow-control.producer.rate.core.api"
- >connection-factory.producer-max-rate</link></entry>
+ >connection-factory.producer-max-rate</link></entry>
<entry>int</entry>
<entry>The max messages per second that can be sent</entry>
<entry>-1</entry>
</row>
<row>
<entry><link linkend="send-guarantees.nontrans.acks"
- >connection-factory.block-on-acknowledge</link></entry>
+ >connection-factory.block-on-acknowledge</link></entry>
<entry>boolean</entry>
<entry>Whether or not we acknowledge messages synchronously</entry>
<entry>false</entry>
</row>
<row>
<entry><link linkend="non-transactional-sends"
- >connection-factory.block-on-non-persistent-send</link></entry>
+ >connection-factory.block-on-non-persistent-send</link></entry>
<entry>boolean</entry>
- <entry>Whether or not we send non persistent messages synchronously</entry>
+ <entry>Whether or not we send non persistent messages
+ synchronously</entry>
<entry>false</entry>
</row>
<row>
<entry><link linkend="non-transactional-sends"
- >connection-factory.block-on-persistent-send</link></entry>
+ >connection-factory.block-on-persistent-send</link></entry>
<entry>boolean</entry>
- <entry>Whether or not we send persistent messages
- synchronously</entry>
+ <entry>Whether or not we send persistent messages synchronously</entry>
<entry>false</entry>
</row>
<row>
@@ -740,25 +753,27 @@
<row>
<entry>connection-factory.dups-ok-batch-size</entry>
<entry>int</entry>
- <entry>The batch size in bytes between acknowledgements when using DUPS_OK_ACKNOWLEDGE mode</entry>
+ <entry>The batch size in bytes between acknowledgements when using
+ DUPS_OK_ACKNOWLEDGE mode</entry>
<entry>1024 * 1024</entry>
</row>
<row>
<entry>connection-factory.transaction-batch-size</entry>
<entry>int</entry>
- <entry>The batch size in bytes between acknowledgements when using a transactional session</entry>
+ <entry>The batch size in bytes between acknowledgements when using a
+ transactional session</entry>
<entry>1024 * 1024</entry>
</row>
<row>
<entry><link linkend="clusters.client.loadbalancing"
- >connection-factory.connection-load-balancing-policy-class-name</link></entry>
+ >connection-factory.connection-load-balancing-policy-class-name</link></entry>
<entry>String</entry>
<entry>The name of the load balancing class</entry>
<entry>org.jboss.messaging.core.client.impl.RoundRobinConnectionLoadBalancingPolicy</entry>
</row>
<row>
<entry><link linkend="clusters-discovery.groups.clientside"
- >connection-factory.discovery-initial-wait-timeout</link></entry>
+ >connection-factory.discovery-initial-wait-timeout</link></entry>
<entry>long</entry>
<entry>The initail time to wait, in milliseconds, for discovery groups
to wait for broadcasts</entry>
@@ -766,21 +781,21 @@
</row>
<row>
<entry><link linkend="thread-pooling.client.side"
- >connection-factory.use-global-pools</link></entry>
+ >connection-factory.use-global-pools</link></entry>
<entry>boolean</entry>
<entry>Use a global thread pool for threads</entry>
<entry>true</entry>
</row>
<row>
<entry><link linkend="thread-pooling.client.side"
- >connection-factory.scheduled-thread-pool-max-size</link></entry>
+ >connection-factory.scheduled-thread-pool-max-size</link></entry>
<entry>int</entry>
<entry>The size of the scheduled thread pool</entry>
<entry>2</entry>
</row>
<row>
<entry><link linkend="thread-pooling.client.side"
- >connection-factory.thread-pool-max-size</link></entry>
+ >connection-factory.thread-pool-max-size</link></entry>
<entry>int</entry>
<entry>The size of the thread pool</entry>
<entry>-1</entry>
@@ -806,7 +821,7 @@
</row>
<row>
<entry><link linkend="ha.client.automatic"
- >connection-factory.failover-on-server-shutdown</link></entry>
+ >connection-factory.failover-on-server-shutdown</link></entry>
<entry>boolean</entry>
<entry>whether or not to failover on server shutdown</entry>
<entry>false</entry>
@@ -816,19 +831,20 @@
>queue</link></entry>
<entry>Queue</entry>
<entry>A queue to create and add to JNDI</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>queue.name (attribute)</entry>
<entry>String</entry>
<entry>Unique name of the queue</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>queue.entry</entry>
<entry>String</entry>
- <entry>Context where the queue will be bound in JNDI. There can be many.</entry>
- <entry></entry>
+ <entry>Context where the queue will be bound in JNDI. There can be
+ many.</entry>
+ <entry/>
</row>
<row>
<entry>queue.durable</entry>
@@ -840,30 +856,31 @@
<entry>queue.filter</entry>
<entry>String</entry>
<entry>Optional filter expression for the queue</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry><link linkend="using-jms.server.configuration"
>topic</link></entry>
<entry>Topic</entry>
<entry>A topic to create and add to JNDI</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>topic.name (attribute)</entry>
<entry>String</entry>
<entry>Unique name of the topic</entry>
- <entry></entry>
+ <entry/>
</row>
<row>
<entry>topic.entry</entry>
<entry>String</entry>
- <entry>Context where the topic will be bound in JNDI. There can be many.</entry>
- <entry></entry>
+ <entry>Context where the topic will be bound in JNDI. There can be
+ many.</entry>
+ <entry/>
</row>
</tbody>
</tgroup>
</table>
</section>
- </section>
+ </section>
</chapter>
Modified: trunk/docs/user-manual/en/master.xml
===================================================================
--- trunk/docs/user-manual/en/master.xml 2009-05-22 09:17:59 UTC (rev 6993)
+++ trunk/docs/user-manual/en/master.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -44,6 +44,7 @@
<!ENTITY using-jms SYSTEM "using-jms.xml">
<!ENTITY using-server SYSTEM "using-server.xml">
<!ENTITY wildcard-syntax SYSTEM "wildcard-syntax.xml">
+ <!ENTITY wildcard-routing SYSTEM "wildcard-routing.xml">
]>
<book lang="en">
<bookinfo>
@@ -63,6 +64,7 @@
&examples;
&embedding-jbm;
&security;
+ &wildcard-routing;
&wildcard-syntax;
&persistence;
&send-guarantees;
Modified: trunk/docs/user-manual/en/security.xml
===================================================================
--- trunk/docs/user-manual/en/security.xml 2009-05-22 09:17:59 UTC (rev 6993)
+++ trunk/docs/user-manual/en/security.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -2,7 +2,11 @@
<chapter id="security">
<title>Security</title>
<para>This chapter describes how security works with JBoss Messaging and how you can configure
- it.</para>
+ it. To disable security completely simply set the <literal>security-enabled</literal>
+ property to false in the <literal>jbm-configuration.xml</literal> file.</para>
+ <para>For performance reasons security is cached and invalidated every so long. To change this
+ period set the property <literal>security-invalidation-interval</literal>, which is in
+ milliseconds. The default is 10000.</para>
<section id="security.settings.roles">
<title>Role based security for addresses</title>
<para>JBoss Messaging contains a flexible role-based security model for applying security to
@@ -50,9 +54,8 @@
<para>For each permission, a list of roles who are granted that permission is specified. If
the user has any of those roles, he/she will be granted that permission for that set of
addresses.</para>
- <para>Let's take a simple example, here's a security block from
- <literal>jbm-configuration.xml</literal> or <literal>jbm-queues.xml</literal>
- file:</para>
+ <para>Let's take a simple example, here's a security block from <literal
+ >jbm-configuration.xml</literal> or <literal>jbm-queues.xml</literal> file:</para>
<programlisting>
<security-setting match="globalqueues.europe.#">
<permission type="createDurableQueue" roles="admin"/>
@@ -154,11 +157,10 @@
creating a session. In this case they will be the user <literal>guest</literal> and have
the role also called <literal>guest</literal>. Multiple roles can be specified for a
default user.</para>
- <para>We then have three more users, the user <literal>tim</literal> has the role
- <literal>admin</literal>. The user <literal>andy</literal> has the roles
- <literal>admin</literal> and <literal>guest</literal>, and the user
- <literal>jeff</literal> has the roles <literal>europe-users</literal> and
- <literal>guest</literal>.</para>
+ <para>We then have three more users, the user <literal>tim</literal> has the role <literal
+ >admin</literal>. The user <literal>andy</literal> has the roles <literal
+ >admin</literal> and <literal>guest</literal>, and the user <literal>jeff</literal>
+ has the roles <literal>europe-users</literal> and <literal>guest</literal>.</para>
</section>
<section>
<title>Changing the security manager</title>
@@ -173,15 +175,15 @@
<stop ignored="true"/>
</bean>
</programlisting>
- <para>The class
- <literal>org.jboss.messaging.core.security.impl.JBMSecurityManagerImpl</literal> is
- the default security manager that reads used by the standalone server.</para>
+ <para>The class <literal
+ >org.jboss.messaging.core.security.impl.JBMSecurityManagerImpl</literal> is the
+ default security manager that reads used by the standalone server.</para>
<para>JBoss Messaging ships with two other security manager implementations you can use off
the shelf - one a JAAS security manager and another for integrating with JBoss
Application Sever security, alternatively you could write your own implementation by
implementing the <literal>org.jboss.messaging.core.security.SecurityManager</literal>
- interface, and specifying the classname of your implementation in the
- <literal>jbm-jboss-beans.xml</literal> file.</para>
+ interface, and specifying the classname of your implementation in the <literal
+ >jbm-jboss-beans.xml</literal> file.</para>
<para>These two implementations are discussed in the next two sections.</para>
</section>
<section>
@@ -233,8 +235,8 @@
<para>The JBoss AS security manager is used when running JBoss Messaging inside the JBoss
Application server. This allows tight integration with the JBoss Application Server's
security model.</para>
- <para>The class name of this security manager is
- <literal>org.jboss.messaging.integration.security.JBossASSecurityManager</literal></para>
+ <para>The class name of this security manager is <literal
+ >org.jboss.messaging.integration.security.JBossASSecurityManager</literal></para>
<para>Take a look at one of the default <literal>jbm-jboss-beans.xml</literal> files for
JBoss Application Server that are bundled in the distribution for an example of how this
is configured.</para>
Modified: trunk/docs/user-manual/en/using-server.xml
===================================================================
--- trunk/docs/user-manual/en/using-server.xml 2009-05-22 09:17:59 UTC (rev 6993)
+++ trunk/docs/user-manual/en/using-server.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -13,8 +13,8 @@
<title>Starting and Stopping the standalone server</title>
<para>In the distribution you will find a directory called <literal>bin</literal>.</para>
<para><literal>cd</literal> into that directory and you'll find a unix/linux script called
- <literal>run.sh</literal> and a windows batch file called
- <literal>run.bat</literal></para>
+ <literal>run.sh</literal> and a windows batch file called <literal
+ >run.bat</literal></para>
<para>To run on Unix/Linux type <literal>./run.sh</literal></para>
<para>To run on Windows type <literal>run.bat</literal></para>
<para>These scripts are very simple and basically just set-up the classpath and some JVM
@@ -79,11 +79,11 @@
<para>For more information on configuring logging, please see the section <link
linkend="logging">configuring logging</link></para>
</section>
- <section>
+ <section id="using-server.configuration">
<title>Configuration files</title>
- <para>The configuration directory is specified on the classpath in the run scripts
- <literal>run.sh</literal> and <literal>run.bat</literal> This directory can contain
- the following files.</para>
+ <para>The configuration directory is specified on the classpath in the run scripts <literal
+ >run.sh</literal> and <literal>run.bat</literal> This directory can contain the
+ following files.</para>
<itemizedlist>
<listitem>
<para><literal>jbm-jboss-beans.xml</literal>. This is the JBoss Microcontainer beans
@@ -102,8 +102,8 @@
<para><literal>jbm-queues.xml</literal>. This file contains pre-defined queues,
queue settings and security settings. The file is optional - all this
configuration can also live in <literal>jbm-configuration.xml</literal>. In
- fact, the default configuration sets do not have a
- <literal>jbm.queues.xml</literal> file. The purpose of allowing queues to be
+ fact, the default configuration sets do not have a <literal
+ >jbm.queues.xml</literal> file. The purpose of allowing queues to be
configured in these files is to allow you to manage your queue configuration
over many files instead of being forced to maintain it in a single file. There
can be many <literal>jbm-queues.xml</literal> files on the classpath. All will
@@ -111,9 +111,9 @@
</listitem>
<listitem>
<para><literal>jbm-users.xml</literal> JBoss Messaging ships with a security manager
- impementation 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 section
+ impementation 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 section
[LINK]</para>
</listitem>
<listitem>
@@ -132,6 +132,11 @@
handler is configured.</para>
</listitem>
</itemizedlist>
+ <note>
+ <para>The property <literal>file-deployment-enabled</literal> in the <literal
+ >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>
</section>
<section id="server.microcontainer.configuration">
<title>JBoss Microcontainer Beans File</title>
@@ -257,9 +262,9 @@
</section>
<section id="usingserver.mainconfig">
<title>The main configuration file.</title>
- <para>The configuration for the JBoss Messaging core server is contained in
- <literal>jbm-configuration.xml</literal>. This is what the FileConfiguration bean
- uses to configure the messaging server.</para>
+ <para>The configuration for the JBoss Messaging core server is contained in <literal
+ >jbm-configuration.xml</literal>. This is what the FileConfiguration bean uses to
+ configure the messaging server.</para>
<para>There are many attributes which you can configure JBoss Messaging. In most cases the
defaults will do fine, in fact every attribute can be defaulted which means a file with
a single empty <literal>configuration</literal> element is a valid configuration file.
Copied: trunk/docs/user-manual/en/wildcard-routing.xml (from rev 6972, trunk/docs/user-manual/en/wildcard-syntax.xml)
===================================================================
--- trunk/docs/user-manual/en/wildcard-routing.xml (rev 0)
+++ trunk/docs/user-manual/en/wildcard-routing.xml 2009-05-22 09:49:41 UTC (rev 6994)
@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<chapter id="wildcard-routing">
+ <title>Routing Messages With Wild Cards</title>
+ <para>JBoss Messaging allows the routing of messages via wildcard addresses. If a consumer is
+ created with an address of say <literal>queue.*</literal> then it will receive any messages
+ sent to addresses that match this, for instance <literal>queue.newsQueue</literal> or
+ <literal>queue.mailQueue</literal>. </para>
+ <para>To enable this functionality set the property <literal>wild-card-routing-enabled</literal>
+ in the <literal>jbm-configuration.xml</literal> file to true. This is true by
+ default.</para>
+ <para>For more information on wild cards take a look at the <link linkend="wildcard-syntax"
+ >wildcard-syntax</link> chapter.</para>
+</chapter>
More information about the jboss-cvs-commits
mailing list