[hornetq-commits] JBoss hornetq SVN: r10403 - trunk/docs/user-manual/en.

do-not-reply at jboss.org do-not-reply at jboss.org
Mon Mar 28 18:22:28 EDT 2011


Author: clebert.suconic at jboss.com
Date: 2011-03-28 18:22:28 -0400 (Mon, 28 Mar 2011)
New Revision: 10403

Modified:
   trunk/docs/user-manual/en/Book_Info.xml
   trunk/docs/user-manual/en/large-messages.xml
   trunk/docs/user-manual/en/paging.xml
Log:
Documentation changes

Modified: trunk/docs/user-manual/en/Book_Info.xml
===================================================================
--- trunk/docs/user-manual/en/Book_Info.xml	2011-03-28 21:14:27 UTC (rev 10402)
+++ trunk/docs/user-manual/en/Book_Info.xml	2011-03-28 22:22:28 UTC (rev 10403)
@@ -20,7 +20,7 @@
   <title>HornetQ User Manual</title>
   <subtitle>Putting the buzz in messaging</subtitle>
   <productname>HornetQ</productname>
-  <edition>2.1.0</edition>
+  <edition>2.2.2</edition>
   <pubsnumber>1</pubsnumber>
   <abstract>
     <para>The User manual is an in depth manual on all aspects of HornetQ</para>

Modified: trunk/docs/user-manual/en/large-messages.xml
===================================================================
--- trunk/docs/user-manual/en/large-messages.xml	2011-03-28 21:14:27 UTC (rev 10402)
+++ trunk/docs/user-manual/en/large-messages.xml	2011-03-28 22:22:28 UTC (rev 10403)
@@ -16,7 +16,6 @@
 <!-- and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent        -->
 <!-- permitted by applicable law.                                                  -->
 <!-- ============================================================================= -->
-
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 <!ENTITY % BOOK_ENTITIES SYSTEM "HornetQ_User_Manual.ent">
 %BOOK_ENTITIES;
@@ -81,6 +80,14 @@
                 on how to instantiate the session factory.</para>
         </section>
         <section>
+            <title>Compressed Large Messages</title>
+            <para>If you specify the boolean property <literal>compress-large-message</literal> on
+                the <literal>server locator</literal> or <literal>ConnectionFactory</literal> The
+                system will use the ZIP algorithm to compress the message body as the message is
+                transfered to the server's side. Notice that there's no special treatment at the
+                server's side, all the compressing and uncompressing is done at the client.</para>
+        </section>
+        <section>
             <title>Using JMS</title>
             <para>If JNDI is used to look up the connection factory, the minimum large message size
                 is specified in <literal>hornetq-jms.xml</literal></para>
@@ -184,9 +191,9 @@
 msg.setInputStream(dataInputStream);
 ...
             </programlisting>
-            
-            <para>Notice also that for messages with more than 2GiB the getBodySize() will return invalid values since 
-            this is an integer (which is also exposed to the JMS API). On those cases you can use the message property _HQ_LARGE_SIZE.</para>
+            <para>Notice also that for messages with more than 2GiB the getBodySize() will return
+                invalid values since this is an integer (which is also exposed to the JMS API). On
+                those cases you can use the message property _HQ_LARGE_SIZE.</para>
         </section>
         <section id="large-messages.streaming.over.jms">
             <title>Streaming over JMS</title>
@@ -258,20 +265,6 @@
    // Do whatever you want with the data
 }        </programlisting>
     </section>
-    <section id="large-messages.cache.client">
-        <title>Cache Large Messages on client</title>
-        <para>Large messages are transferred by streaming from server to client. The message is
-            broken into smaller packets and as the message is read more packets will be received.
-            Because of that the body of the large message can be read only once, and by consequence
-            a received message can be sent to another producer only once. The JMS Bridge for
-            instance won't be able to resend a large message in case of failure</para>
-        <para>To solve this problem, you can enable the property <literal
-                >cache-large-message-client</literal> on the connection factory. If you enable this
-            property the client consumer will create a temporary file to hold the large message
-            content, so it would be possible to resend large messages.</para>
-        <note>Use this option on the connection factory used by the JMS Bridge if the JMS Bridge is
-            being used for large messages.</note>
-    </section>
     <section id="large-messages.example">
         <title>Large message example</title>
         <para>Please see <xref linkend="examples.large-message"/> for an example which shows how

Modified: trunk/docs/user-manual/en/paging.xml
===================================================================
--- trunk/docs/user-manual/en/paging.xml	2011-03-28 21:14:27 UTC (rev 10402)
+++ trunk/docs/user-manual/en/paging.xml	2011-03-28 22:22:28 UTC (rev 10403)
@@ -140,6 +140,13 @@
                                     they try and send further messages.</entry>
                                 <entry>PAGE</entry>
                             </row>
+                            <row>
+                                <entry><literal>page-max-cache-size</literal></entry>
+                                <entry>The system will keep up to &lt;<literal
+                                        >page-max-cache-size</literal> page files in memory to
+                                    optimize IO during paging navigation.</entry>
+                                <entry>5</entry>
+                            </row>
                         </tbody>
                     </tgroup>
                 </table>
@@ -190,9 +197,8 @@
                 <para>The other 9 queues are empty even though messages have been sent.</para>
             </listitem>
         </itemizedlist>
-        <para>In this example we have to wait until the last queue has delivered some of its
-            messages before we depage and the other queues finally receive some more
-            messages.</para>
+        <para>In this example all the other 9 queues will be consuming messages from the page
+            system. This may cause performance issues if this is an undesirable state.</para>
     </section>
     <section>
         <title>Example</title>



More information about the hornetq-commits mailing list