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

Author: clebert.suconic(a)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>