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
<<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>
Show replies by date