Author: ataylor Date: 2010-01-08 04:40:20 -0500 (Fri, 08 Jan 2010) New Revision: 8776 Modified: trunk/docs/user-manual/en/examples.xml Log: doc fix Modified: trunk/docs/user-manual/en/examples.xml =================================================================== --- trunk/docs/user-manual/en/examples.xml 2010-01-07 22:43:11 UTC (rev 8775) +++ trunk/docs/user-manual/en/examples.xml 2010-01-08 09:40:20 UTC (rev 8776) @@ -48,16 +48,15 @@ uncommitted work in the old session will be lost, and any unacknowledged messages might be redelivered.</para> </section> - <section> - <title>Automatic Reconnect</title> - <para>The <literal>reconnect-same-node</literal> example demonstrates how HornetQ - connections can be configured to be resilient to temporary network failures.</para> - <para> In the case of a network failure being detected, either as a result of a failure - to read/write to the connection, or the failure of a pong to arrive back from the - server in good time after a ping is sent, instead of failing the connection - immediately and notifying any user <literal>ExceptionListener</literal> objects, - HornetQ can be configured to automatically retry the connection, and reconnect to - the server when it becomes available again across the network.</para> + <section id="examples.bridge"> + <title>Core Bridge Example</title> + <para>The <literal>bridge</literal> example demonstrates a core bridge deployed on one + server, which consumes messages from a local queue and forwards them to an address + on a second server.</para> + <para>Core bridges are used to create message flows between any two HornetQ servers + which are remotely separated. Core bridges are resilient and will cope with + temporary connection failure allowing them to be an ideal choice for forwarding over + unreliable connections, e.g. a WAN.</para> </section> <section id="examples.browsers"> <title>Browser</title> @@ -69,16 +68,6 @@ without removing them. It can scan the entire content of a queue or only messages matching a message selector.</para> </section> - <section id="examples.bridge"> - <title>Core Bridge Example</title> - <para>The <literal>bridge</literal> example demonstrates a core bridge deployed on one - server, which consumes messages from a local queue and forwards them to an address - on a second server.</para> - <para>Core bridges are used to create message flows between any two HornetQ servers - which are remotely separated. Core bridges are resilient and will cope with - temporary connection failure allowing them to be an ideal choice for forwarding over - unreliable connections, e.g. a WAN.</para> - </section> <section> <title>Client Kickoff</title> <para>The <literal>client-kickoff</literal> example shows how to terminate client @@ -121,6 +110,15 @@ of the nodes. We then send some messages via the producer, and we verify that both subscribers receive all the sent messages.</para> </section> + <section id="examples.consumer-rate-limit"> + <title>Message Consumer Rate Limiting</title> + <para>With HornetQ you can specify a maximum consume rate at which a JMS MessageConsumer + will consume messages. This can be specified when creating or deploying the + connection factory.</para> + <para>If this value is specified then HornetQ will ensure that messages are never + consumed at a rate higher than the specified rate. This is a form of consumer + throttling.</para> + </section> <section id="examples.dead-letter"> <title>Dead Letter</title> <para>The <literal>dead-letter</literal> example shows you how to define and deal with @@ -247,15 +245,6 @@ closed, addresses are created or deleted, security authentication fails, etc.).</para> </section> - <section id="examples.consumer-rate-limit"> - <title>Message Consumer Rate Limiting</title> - <para>With HornetQ you can specify a maximum consume rate at which a JMS MessageConsumer - will consume messages. This can be specified when creating or deploying the - connection factory.</para> - <para>If this value is specified then HornetQ will ensure that messages are never - consumed at a rate higher than the specified rate. This is a form of consumer - throttling.</para> - </section> <section id="examples.message-counters"> <title>Message Counter</title> <para>The <literal>message-counters</literal> example shows you how to use message @@ -297,12 +286,6 @@ <para>The <literal>message-group2</literal> example shows you how to configure and use message groups with HornetQ via a connection factory.</para> </section> - <section id="producer-rate-limiting-example"> - <title>Message Producer Rate Limiting</title> - <para>The <literal>producer-rte-limit</literal> example demonstrates how, with HornetQ, - you can specify a maximum send rate at which a JMS message producer will send - messages.</para> - </section> <section id="examples.message-priority"> <title>Message Priority</title> <para>Message Priority can be used to influence the delivery order for messages.</para> @@ -316,12 +299,6 @@ at their destinations. Please consult the JMS 1.1 specification for full details.</para> </section> - <section> - <title>Message Redistribution</title> - <para>The <literal>queue-message-redistribution</literal> example demonstrates message - redistribution between queues with the same name deployed in different nodes of a - cluster.</para> - </section> <section id="examples.no-consumer-buffering"> <title>No Consumer Buffering</title> <para>By default, HornetQ consumers buffer messages from the server in a client side @@ -368,11 +345,23 @@ delivering it to the client. This example demonstrates how HornetQ allows this with an extra acknowledgement mode.</para> </section> + <section id="producer-rate-limiting-example"> + <title>Message Producer Rate Limiting</title> + <para>The <literal>producer-rte-limit</literal> example demonstrates how, with HornetQ, + you can specify a maximum send rate at which a JMS message producer will send + messages.</para> + </section> <section> <title>Queue</title> <para>A simple example demonstrating a JMS queue.</para> </section> <section> + <title>Message Redistribution</title> + <para>The <literal>queue-message-redistribution</literal> example demonstrates message + redistribution between queues with the same name deployed in different nodes of a + cluster.</para> + </section> + <section> <title>Queue Requestor</title> <para>A simple example demonstrating a JMS queue requestor.</para> </section> @@ -382,7 +371,15 @@ messages using message selectors with queue consumers.</para> </section> <section> - <title>Request-Response</title> + <title>Reattach Node example</title> + <para>The <literal>Reattach Node</literal> example shows how a client can try to reconnect to + the same server instead of failing the connection immediately and + notifying any user ExceptionListener objects. HornetQ can be configured to automatically + retry the connection, and reattach to the server when it becomes available again across + the network.</para> + </section> + <section> + <title>Request-Reply example</title> <para>A simple example showing the JMS request-response pattern.</para> </section> <section id="examples.scheduled-message"> @@ -404,6 +401,11 @@ processed in a separate stream to the sent messages. </para> </section> <section> + <title>SSL Transport</title> + <para>The <literal>ssl-enabled</literal> shows you how to configure SSL with HornetQ to + send and receive message.</para> + </section> + <section> <title>Static Message Selector</title> <para>The <literal>static-selector</literal> example shows you how to configure a HornetQ core queue with static message selectors (filters).</para> @@ -414,11 +416,6 @@ HornetQ queue with static message selectors (filters) using JMS.</para> </section> <section> - <title>SSL Transport</title> - <para>The <literal>ssl-enabled</literal> shows you how to configure SSL with HornetQ to - send and receive message.</para> - </section> - <section> <title>Symmetric Cluster</title> <para>The <literal>symmetric-cluster</literal> example demonstrates a symmetric cluster set-up with HornetQ.</para>