8:44 a.m.
Author: ataylor
Date: 2010-01-08 09:44:04 -0500 (Fri, 08 Jan 2010)
New Revision: 8780
Modified:
trunk/examples/jms/applet/readme.html
trunk/examples/jms/application-layer-failover/readme.html
trunk/examples/jms/client-kickoff/readme.html
trunk/examples/jms/client-side-load-balancing/readme.html
trunk/examples/jms/clustered-grouping/readme.html
trunk/examples/jms/clustered-standalone/readme.html
trunk/examples/jms/dead-letter/readme.html
trunk/examples/jms/delayed-redelivery/readme.html
trunk/examples/jms/durable-subscription/readme.html
Log:
example read me updates part 1
Modified: trunk/examples/jms/applet/readme.html
===================================================================
--- trunk/examples/jms/applet/readme.html 2010-01-08 14:20:38 UTC (rev 8779)
+++ trunk/examples/jms/applet/readme.html 2010-01-08 14:44:04 UTC (rev 8780)
@@ -12,7 +12,7 @@
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i> to start
- HornetQ server and a HTTP server.</p>
+ the HornetQ server and an HTTP server.</p>
<p>Then, go to <a
href="http://127.0.0.1:8088/applet.html">http://127.0.0.1:8088/applet.html</a>
to load
and use the applet.</p>
Modified: trunk/examples/jms/application-layer-failover/readme.html
===================================================================
--- trunk/examples/jms/application-layer-failover/readme.html 2010-01-08 14:20:38 UTC (rev
8779)
+++ trunk/examples/jms/application-layer-failover/readme.html 2010-01-08 14:44:04 UTC (rev
8780)
@@ -8,13 +8,12 @@
<body onload="prettyPrint()">
<h1>Application-Layer Failover Example</h1>
- <p>HornetQ implements fully transparent <b>automatic</b> failover
of connections from a live to backup node, this requires
- no special coding for failover, and is described in a different example. Automatic
failover requires server replication.</p>
- <p>However, HornetQ also supports <b>Application-Layer</b>
failover, useful in the case that replication is not enabled
- on the server side.</p>
- <p>With Application-Layer failover, it's up to the application to register
a JMS ExceptionListener with HornetQ which will be
- called by HornetQ in the event that connection failure is detected.</p>
- <p>The code in the ExceptionListener then recreates the JMS Connection,
Session, etc on another node and the application
+ <p>HornetQ implements fully transparent <b>automatic</b> failover
of connections from a live node to a backup node which requires
+ no special coding. This is described in a different example and requires server
replication.</p>
+ <p>However, HornetQ also supports <b>Application-Layer</b>
failover which is useful in the case where replication is not enabled.</p>
+ <p>With Application-Layer failover, it's up to the application to register
a JMS ExceptionListener with HornetQ.
+ This listener will then be called by HornetQ in the event that connection
failure is detected.</p>
+ <p>User code in the ExceptionListener can then recreate any JMS Connection,
Session, etc on another node and the application
can continue.</p>
<p>Application-Layer failover is an alternative approach to High Availabilty
(HA).</p>
<p>Application-Layer failover differs from automatic failover in that some
client side coding is required in order
Modified: trunk/examples/jms/client-kickoff/readme.html
===================================================================
--- trunk/examples/jms/client-kickoff/readme.html 2010-01-08 14:20:38 UTC (rev 8779)
+++ trunk/examples/jms/client-kickoff/readme.html 2010-01-08 14:44:04 UTC (rev 8780)
@@ -12,7 +12,7 @@
using <a
href="http://java.sun.com/javase/technologies/core/mntr-mgmt/javaman...
<p>The example will connect to HornetQ. Using JMX, we will list the remote
addresses connected to the
- server and close the corresponding connections. The client will be kicked off
from HornetQ and receives
+ server and close the corresponding connections. The client will be kicked off
from HornetQ receiving
an exception that its JMS connection was interrupted.</p>
<h2>Example configuration</h2>
@@ -26,7 +26,7 @@
-Dcom.sun.management.jmxremote.authenticate=false</code>
</pre>
<p>These properties are explained in the Java 5 <a
href="http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.htm...
guide</a>
- (please note that for this example, we will disable user authentication for
simplicity sake).</p>
+ (please note that for this example, we will disable user authentication for
simplicity).</p>
<p>With these properties, HornetQ server will be manageable remotely using
standard JMX URL on port <code>3000</code>.</p>
</p>
Modified: trunk/examples/jms/client-side-load-balancing/readme.html
===================================================================
--- trunk/examples/jms/client-side-load-balancing/readme.html 2010-01-08 14:20:38 UTC (rev
8779)
+++ trunk/examples/jms/client-side-load-balancing/readme.html 2010-01-08 14:44:04 UTC (rev
8780)
@@ -15,7 +15,7 @@
guide for more details of how to configure the specific load-balancing policy. In
this example we will use
the default round-robin load balancing policy.</p>
<p>The list of servers over which HornetQ will round-robin the connections can
either be specified explicitly
- in the connection factory when creating it, or deploying it on the server, or the
factory can be configured
+ in the connection factory when instantiating it directly, when configuring it on the
server or configured
to use UDP discovery to discover the list of servers over which to round-robin. This
example will use UDP
discovery to obtain the list.</p>
<p>This example starts three servers which all broadcast their location using
UDP discovery. The UDP broadcast configuration
@@ -31,9 +31,7 @@
<ol>
<li> Get an initial context for looking up JNDI from server 0.</li>
<pre class="prettyprint">>
- <code>
- initialContext = getContext(0);
- </code>
+ <code>initialContext = getContext(0);</code>
</pre>
<li>Look-up the JMS Queue object from JNDI</li>
Modified: trunk/examples/jms/clustered-grouping/readme.html
===================================================================
--- trunk/examples/jms/clustered-grouping/readme.html 2010-01-08 14:20:38 UTC (rev 8779)
+++ trunk/examples/jms/clustered-grouping/readme.html 2010-01-08 14:44:04 UTC (rev 8780)
@@ -8,7 +8,8 @@
<p>This example demonstrates how to ensure strict ordering across a cluster
using clustered message grouping</p>
<p>We create 3 nodes each with a grouping message handler, one with a Local
handler and 2 with a Remote handler.</p>
- <p>The local handler acts as an arbitrator for the 2 remote handlers, holding
the information on routes and communicating that with the remote handlers</p>
+ <p>The local handler acts as an arbitrator for the 2 remote handlers, holding
the information on routes and communicating
+ the routing info with the remote handlers on the other 2 nodes</p>
<p>We then send some messages to each node with the same group id set and
ensure the same consumer receives all of them</p>
<p>Here's the relevant snippet from the server configuration that has the
local handler</p>
<pre>
Modified: trunk/examples/jms/clustered-standalone/readme.html
===================================================================
--- trunk/examples/jms/clustered-standalone/readme.html 2010-01-08 14:20:38 UTC (rev
8779)
+++ trunk/examples/jms/clustered-standalone/readme.html 2010-01-08 14:44:04 UTC (rev
8780)
@@ -10,7 +10,7 @@
<p>This example demonstrates a JMS Topic deployed on three different nodes.
The three nodes are configured to form a cluster.</p>
- <p>Subscriber for the topic are created on each node, and a producer is
created on only one of the nodes.</p>
+ <p>Subscribers for the topic are created on each node, and a producer is
created on only one of the nodes.</p>
<p>Some messages are sent by the producer, and we verify that
<strong>all</strong> subscribers receive all the
sent messages.</p>
<p>This example uses HornetQ's default stand-alone clustered
configuration.
Modified: trunk/examples/jms/dead-letter/readme.html
===================================================================
--- trunk/examples/jms/dead-letter/readme.html 2010-01-08 14:20:38 UTC (rev 8779)
+++ trunk/examples/jms/dead-letter/readme.html 2010-01-08 14:44:04 UTC (rev 8780)
@@ -13,9 +13,9 @@
Such a message goes back to the JMS destination ready to be redelivered.
However, this means it is possible for a message to be delivered again and again
without any success and remain in the destination, clogging the system.</p>
<p>To prevent this, messaging systems define dead letter messages: after a
specified unsuccessful delivery attempts, the message is removed from the destination
- and put instead in a <em>dead letter address</em> where they can be
consumed for further investigation.
+ and instead routed to a <em>dead letter address</em> where they can
be consumed for further investigation.
<p>
- The example will show how to configure HornetQ to send a message to a dead
letter destination after 3 unsuccessful delivery attempts.<br />
+ The example will show how to configure HornetQ to route a message to a dead
letter address after 3 unsuccessful delivery attempts.<br />
The example will send 1 message to a queue. We will deliver the message 3 times
and rollback the session every time.<br />
On the 4th attempt, there won't be any message to consume: it will have been
moved to a <em>dead letter address</em>.<br />
We will then consume this dead letter message.
Modified: trunk/examples/jms/delayed-redelivery/readme.html
===================================================================
--- trunk/examples/jms/delayed-redelivery/readme.html 2010-01-08 14:20:38 UTC (rev 8779)
+++ trunk/examples/jms/delayed-redelivery/readme.html 2010-01-08 14:44:04 UTC (rev 8780)
@@ -9,7 +9,7 @@
<h1>Delayed Redelivery Example</h1>
<p>This example demonstrates how HornetQ can be configured to provide a
delayed redelivery in the case
- a message needs to be redelivered.</p>
+ where a message needs to be redelivered.</p>
<p>Delaying redelivery can often be useful in the case that clients regularly
fail or roll-back. Without a delayed
redelivery, the system can get into a "thrashing" state, with delivery
being attempted, the client rolling back, and
delivery being re-attempted ad infinitum in quick succession, using up valuable CPU
and network resources.</p>
Modified: trunk/examples/jms/durable-subscription/readme.html
===================================================================
--- trunk/examples/jms/durable-subscription/readme.html 2010-01-08 14:20:38 UTC (rev
8779)
+++ trunk/examples/jms/durable-subscription/readme.html 2010-01-08 14:44:04 UTC (rev
8780)
@@ -8,9 +8,12 @@
<body onload="prettyPrint()">
<h1>JMS Durable Subscription Example</h1>
- <p>This example shows you how to use a durable subscription with
HornetQ.</p>
+ <p>This example demonstrates how to use a durable subscription with
HornetQ.</p>
<p>Durable subscriptions are a standard part of JMS, please consult the JMS
1.1 specification for full details.</p>
- <p>Unlike non durable subscriptions, the key function of durable subscriptions
is that the messages contained in them persist longer than the lifetime of the subscriber
- i.e. they will accumulate messages sent to the topic even if there is no active
subscriber on them. They will also survive server restarts. Note that for the messages to
be persisted, the messages sent to them must be marked as persistent messages.</p>
+ <p>Unlike non durable subscriptions, the key function of durable subscriptions
is that the messages contained in them
+ persist longer than the lifetime of the subscriber - i.e. they will accumulate
messages sent to the topic even
+ if the subscriber is not currently connected. They will also survive server
restarts. Note that for the messages to
+ be persisted, the messages sent to them must be marked as persistent
messages.</p>
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>