[hornetq-commits] JBoss hornetq SVN: r8780 - in trunk/examples/jms: application-layer-failover and 7 other directories.

do-not-reply at jboss.org do-not-reply at jboss.org
Fri Jan 8 09:44:04 EST 2010


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/javamanagement/">JMX</a></p>
 
      <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.html#remote">Management 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>



More information about the hornetq-commits mailing list