qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oru...@apache.org
Subject [12/51] [partial] qpid-site git commit: Update site for release 6.1.2 of Qpid for Java
Date Wed, 22 Mar 2017 11:11:54 GMT
diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Disk-Space-Management.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Disk-Space-Management.html.in
new file mode 100644
index 0000000..2a5d3d0
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Disk-Space-Management.html.in
@@ -0,0 +1,96 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.2.&#160;Disk Space Management</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Producer-Transaction-Timeout.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Disk-Space-Management"></a>9.2.&#160;Disk Space Management</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Qpid-Producer-Flow-Control"></a>9.2.1.&#160;Producer Flow Control</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control-Ge
 neralInformation"></a>;General Information</h4></div></div></div><p>
+            The Apache Qpid Broker for Java supports a flow control mechanism to which can be used to prevent either a single queue
+            or a virtualhost exceeding configured limits.  These two mechanisms are described
+            next.
+        </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control-ServerConfiguration"></a>;Server Configuration</h4></div></div></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e5917"></a>Configuring a Queue to use flow control</h5></div></div></div><p>
+                Flow control is enabled on a producer when it sends a message to a Queue
+                which is "overfull". The producer flow control will be rescinded when all
+                Queues on which a producer is blocking become "underfull". A Queue is defined
+                as overfull when the size (in bytes) of the messages on the queue exceeds the
+                <span class="emphasis"><em>capacity</em></span> of the Queue. A Queue becomes "underfull" when its
+                size becomes less than the <span class="emphasis"><em>resume capacity</em></span>.
+            </p><p>
+                The capacity and resume capacity can be specified when the queue is created.  This
+                can be done using the Flow Control Settings within the Queue creation dialogue.
+            </p><div class="section"><div class="titlepage"><div><div><h6 class="title"><a id="d0e5930"></a>Broker Log Messages</h6></div></div></div><p>
+                    There are four Broker log messages that may occur if flow control through queue capacity limits is enabled.
+                    Firstly, when a capacity limited queue becomes overfull, a log message similar to the following is produced
+                </p><pre class="programlisting">
+MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1003 : Overfull : Size : 1,200 bytes, Capacity : 1,000
+                </pre><p>Then for each channel which becomes blocked upon the overful queue a log message similar to the following is produced:</p><pre class="programlisting">
+MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1005 : Flow Control Enforced (Queue MyQueue)
+                </pre><p>When enough messages have been consumed from the queue that it becomes underfull, then the following log is generated: </p><pre class="programlisting">
+MESSAGE [vh(/test)/qu(MyQueue)] [vh(/test)/qu(MyQueue)] QUE-1004 : Underfull : Size : 600 bytes, Resume Capacity : 800
+                </pre><p>And for every channel which becomes unblocked you will see a message similar to: </p><pre class="programlisting">
+MESSAGE [con:2(guest@anonymous(713889609)/test)/ch:1] [con:2(guest@anonymous(713889609)/test)/ch:1] CHN-1006 : Flow Control Removed
+                </pre><p>Obviously the details of connection, virtual host, queue, size, capacity, etc would depend on the configuration in use.</p></div></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e5953"></a>Disk quota-based flow control</h5></div></div></div><p>
+                Flow control can also be triggered when a configured disk quota is exceeded. This is supported by the BDB and
+                Derby virtualhosts.
+            </p><p>
+                This functionality blocks all producers on reaching the disk overflow limit. When consumers
+                consume the messages, causing disk space usage to falls below the underflow limit, the
+                producers are unblocked and continue working as normal.
+            </p><p>
+                Two limits can be configured:
+            </p><p>
+                overfull limit - the maximum space on disk (in bytes).
+            </p><p>
+                underfull limit - when the space on disk drops below this limit, producers are allowed to resume publishing.
+            </p><p>
+                The overfull and underful limit can be specified when a new virtualhost is created or an exiting
+                virtualhost is edited.  This can be done using the Store Overflow and Store Underfull settings
+                within the virtual host creation and edit dialogue.  If editing an existing virtualhost, the virtualhost
+                must be restarted for the new values to take effect.
+            </p><p>
+                The disk quota functionality is based on "best effort" principle. This means the broker
+                cannot guarantee that the disk space limit will not be exceeded. If several concurrent
+                transactions are started before the limit is reached, which collectively cause the limit
+                to be exceeded, the broker may allow all of them to be committed.
+            </p><p>
+                The Broker will also impose flow control if the filesystem hosting a virtualhost
+                exceeds a <a class="link" href="Java-Broker-Management-Managing-Broker.html#Java-Broker-Management-Managing-Broker-Context-StoreFilesystemMaxUsagePercent">
+                    configured percentage.</a>.
+            </p><div class="section"><div class="titlepage"><div><div><h6 class="title"><a id="d0e5975"></a>Broker Log Messages for quota flow control</h6></div></div></div><p>
+                    There are two broker log messages that may occur if flow control through disk quota limits is enabled.
+                    When the virtual host is blocked due to exceeding of the disk quota limit the following message
+                    appears in the broker log
+                    </p><pre class="programlisting">
+[vh(/test)/ms(BDBMessageStore)] MST-1008 : Store overfull, flow control will be enforced
+                    </pre><p>
+                    When virtual host is unblocked after cleaning the disk space the following message appears in the broker log
+                    </p><pre class="programlisting">
+[vh(/test)/ms(BDBMessageStore)] MST-1009 : Store overfull condition cleared
+                    </pre><p>
+                </p></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Disk-Space-Management-Producer-Flow-Control-ClientImpact"></a>;Client impact and configuration</h4></div></div></div><p>
+            If a producer sends to a queue which is overfull, the broker will respond by
+            instructing the client not to send any more messages. The impact of this is
+            that any future attempts to send will block until the broker rescinds the flow control order.
+        </p><p>
+            While blocking the client will periodically log the fact that it is blocked waiting on flow control.
+        </p><pre class="programlisting">
+WARN   Message send delayed by 5s due to broker enforced flow control
+WARN   Message send delayed by 10s due to broker enforced flow control
+        </pre><p>
+            After a set period the send will timeout and throw a JMSException to the calling code.
+        </p><p>
+            If such a JMSException is thrown, the message will not be sent to the broker,
+            however the underlying Session may still be active - in particular if the
+            Session is transactional then the current transaction will not be automatically
+            rolled back. Users may choose to either attempt to resend the message, or to
+            roll back any transactional work and close the Session.
+        </p><p>
+            Both the timeout delay and the periodicity of the warning messages can be set
+            using Java system properties.
+        </p><p>
+            The amount of time (in milliseconds) to wait before timing out
+            is controlled by the property qpid.flow_control_wait_failure.
+        </p><p>
+            The frequency at which the log message informing that the producer is flow
+            controlled is sent is controlled by the system property qpid.flow_control_wait_notify_period.
+        </p><p>
+            Adding the following to the command line to start the client would result in a timeout of one minute,
+            with warning messages every ten seconds:
+        </p><pre class="programlisting">
+        </pre></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Producer-Transaction-Timeout.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">Chapter&#160;9.&#160;Runtime&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.3.&#160;Producer Transaction Timeout</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Flow-To-Disk.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Flow-To-Disk.html.in
new file mode 100644
index 0000000..a483ae0
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Flow-To-Disk.html.in
@@ -0,0 +1,16 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.6.&#160;Flow to Disk</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Close-Connection-When-No-Route.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Consumers.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Flow-To-Disk"></a>9.6.&#160;Flow to Disk</h2></div></div></div><p>Flow to disk limits the amount of <a class="link" href="Java-Broker-Runtime-Memory.html" title="9.11.&#160;Memory">direct and heap memory</a>
+    that can be occupied by messages. Once this
+    limit is reached any new transient messages and all existing transient messages will be
+    transferred to disk. Newly arriving transient messages will continue to go to the disk until the
+    cumulative size of all messages falls below the limit once again.</p><p>By default the Broker makes 40% of the max direct available memory for messages. This memory is
+    divided between all the queues across all virtual hosts defined on the Broker with a percentage
+    calculated according to their current queue size. These calculations are refreshed periodically
+    by the housekeeping cycle.</p><p>For example if there are two queues, one containing 75MB and the second 100MB messages
+    respectively and the Broker has 1GB direct memory with the default of 40% available for messages.
+    The first queue will have a target size of 170MB and the second 230MB. Once 400MB is taken by
+    messages, messages will begin to flow to disk. New messages will cease to flow to disk when
+    their cumulative size falls beneath 400MB.</p><p>Flow to disk is configured by Broker context variable
+      <code class="literal">broker.flowToDiskThreshold</code>. It is expressed as a size in bytes and defaults
+    to 40% of the JVM maximum heap size.</p><p>Log message <a class="link" href="Java-Broker-Appendix-Operation-Logging.html#Java-Broker-Appendix-Operation-Logging-Message-BRK-1014">BRK-1014</a> is written when the feature activates. Once the total space of all messages
+    decreases below the threshold, the message <a class="link" href="Java-Broker-Appendix-Operation-Logging.html#Java-Broker-Appendix-Operation-Logging-Message-BRK-1015">BRK-1015</a> is written
+    to show that the feature is no longer active.</p></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime-Close-Connection-When-No-Route.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Consumers.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">9.5.&#160;Closing client connections on unroutable mandatory messages&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.7.&#160;Consumers</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Handling-Undeliverable-Messages.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Handling-Undeliverable-Messages.html.in
new file mode 100644
index 0000000..b5f0709
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Handling-Undeliverable-Messages.html.in
@@ -0,0 +1,39 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.4.&#160;Handing Undeliverable Messages</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Producer-Transaction-Timeout.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Close-Connection-When-No-Route.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Handling-Undeliverable-Messages"></a>9.4.&#160;Handing Undeliverable Messages</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Introduction"></a>9.4.1.&#160;Introduction</h3></div></div></div><p> Messages that cannot be delivered successfully to a c
 onsumer (for instance, because the
+   client is using a transacted session and rolls-back the transaction) can be made available on
+   the queue again and then subsequently be redelivered, depending on the precise session
+   acknowledgement mode and messaging model used by the application. This is normally desirable
+   behaviour that contributes to the ability of a system to withstand unexpected errors. However, it
+   leaves open the possibility for a message to be repeatedly redelivered (potentially indefinitely),
+   consuming system resources and preventing the delivery of other messages. Such undeliverable
+   messages are sometimes known as poison messages.</p><p>For an example, consider a stock ticker application that has been designed to consume prices
+   contained within JMS TextMessages. What if inadvertently a BytesMessage is placed onto the queue?
+   As the ticker application does not expect the BytesMessage, its processing might fail and cause it
+   to roll-back the transaction, however the default behavior of the Broker would mean that the
+   BytesMessage would be delivered over and over again, preventing the delivery of other legitimate
+   messages, until an operator intervenes and removes the erroneous message from the queue. </p><p>Qpid has maximum delivery count and dead-letter queue (DLQ) features which can be used in
+   concert to construct a system that automatically handles such a condition. These features are
+   described in the following sections.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Maximum-Delivery-Count"></a>9.4.2.&#160;Maximum Delivery Count</h3></div></div></div><p> Maximum delivery count is a property of a queue. If a consumer application is unable to
+   process a message more than the specified number of times, then the broker will either route the
+   message to a dead-letter queue (if one has been defined), or will discard the message. </p><p> In order for a maximum delivery count to be enforced, the consuming client
+    <span class="emphasis"><em>must</em></span> call <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/Session.html#rollback()" target="_top">Session#rollback()</a> (or <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/Session.html#recover()" target="_top">Session#recover()</a> if the session is not transacted). It is during the Broker's
+   processing of Session#rollback() (or Session#recover()) that if a message has been seen
+   at least the maximum number of times then it will move the message to the DLQ or discard the
+   message.</p><p>If the consuming client fails in another manner, for instance, closes the connection, the
+   message will not be re-routed and consumer application will see the same poison message again
+   once it reconnects.</p><p> If the consuming application is using AMQP 0-9-1, 0-9, or 0-8 protocols, it is necessary to
+   set the client system property <code class="varname">qpid.reject.behaviour</code> or connection or binding
+   URL option <code class="varname">rejectbehaviour</code> to the value <code class="literal">server</code>.</p><p>It is possible to determine the number of times a message has been sent to a consumer via
+   the Management interfaces, but is not possible to determine this information from a message client.
+   Specifically, the optional JMS message header <span class="property">JMSXDeliveryCount</span> is not
+   supported.</p><p>Maximum Delivery Count can be specified when a new queue is created or using the the
+   queue declare property <span class="property">x-qpid-maximum-delivery-count</span></p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Dead-Letter-Queues"></a>9.4.3.&#160;Dead Letter Queues (DLQ)</h3></div></div></div><p>A Dead Letter Queue (DLQ) acts as an destination for messages that have somehow exceeded the
+   normal bounds of processing and is utilised to prevent disruption to flow of other messages. When
+   a DLQ is enabled for a given queue if a consuming client indicates it no longer wishes the
+   receive the message (typically by exceeding a Maximum Delivery Count) then the message is moved
+   onto the DLQ and removed from the original queue. </p><p>The DLQ feature causes generation of a Dead Letter Exchange and a Dead Letter Queue. These
+   are named convention QueueName<span class="emphasis"><em>_DLE</em></span> and QueueName<span class="emphasis"><em>_DLQ</em></span>.</p><p>DLQs can be enabled when a new queue is created
+   or using the queue declare property <span class="property">x-qpid-dlq-enabled</span>.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Avoid excessive queue depth</h3><p>Applications making use of DLQs <span class="emphasis"><em>should</em></span> make provision for the frequent
+    examination of messages arriving on DLQs so that both corrective actions can be taken to resolve
+    the underlying cause and organise for their timely removal from the DLQ. Messages on DLQs
+    consume system resources in the same manner as messages on normal queues so excessive queue
+    depths should not be permitted to develop.</p></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime-Producer-Transaction-Timeout.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Close-Connection-When-No-Route.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">9.3.&#160;Producer Transaction Timeout&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.5.&#160;Closing client connections on unroutable mandatory messages</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Memory.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Memory.html.in
new file mode 100644
index 0000000..be585d6
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Memory.html.in
@@ -0,0 +1,127 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.11.&#160;Memory</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Connection-Limit.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-High-Availability.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Memory"></a>9.11.&#160;Memory</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Introduction"></a>9.11.1.&#160;Introduction</h3></div></div></div><p>
+      Understanding how the Qpid broker uses memory is essential to running a high performing and reliable service.
+      A wrongly configured broker can exhibit poor performance or even crash with an <code class="literal">OutOfMemoryError</code>.
+      Unfortunately, memory usage is not a simple topic and thus requires some in depth explanations.
+      This page should give the required background information to make informed decisions on how to configure your broker.
+    </p><p>
+      <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Types" title="9.11.2.&#160;Types of Memory">Section&#160;9.11.2, &#8220;Types of Memory&#8221;</a> explains the two different kinds of Java memory most relevant to the broker.
+      <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Usage" title="9.11.3.&#160;Memory Usage in the Broker">Section&#160;9.11.3, &#8220;Memory Usage in the Broker&#8221;</a> goes on to explain which parts of the broker use what kind of memory.
+      <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Low-Memory" title="9.11.4.&#160;Low Memory Conditions">Section&#160;9.11.4, &#8220;Low Memory Conditions&#8221;</a> explains what happens when the system runs low on memory.
+      <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Defaults" title="9.11.5.&#160;Defaults">Section&#160;9.11.5, &#8220;Defaults&#8221;</a> lays out the default settings of the Qpid broker.
+      Finally, <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Tuning" title="9.11.6.&#160;Memory Tuning the Broker">Section&#160;9.11.6, &#8220;Memory Tuning the Broker&#8221;</a> gives some advice on tuning your broker.
+    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Types"></a>9.11.2.&#160;Types of Memory</h3></div></div></div><p>
+      While Java has a couple of different internal memory types we will focus on the two types that are relevant to the Qpid broker.
+      Both of these memory types are taken from the same physical memory (RAM).
+    </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6474"></a>;Heap</h4></div></div></div><p>
+        Normally, all objects are allocated from Java's heap memory.
+        Once, nothing references an object it is cleaned up by the Java Garbage Collector and it's memory returned to the heap.
+        This works fine for most use cases.
+        However, when interacting with other parts of the operating system using Java's heap is not ideal.
+        This is where the so called direct memory comes into play.
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6479"></a>;Direct</h4></div></div></div><p>
+        The world outside of the JVM, in particular the operating system (OS), does not know about Java heap memory and uses other structures like C arrays.
+        In order to interact with these systems Java needs to copy data between its own heap memory and these native structures.
+        This can become a bottle neck when there is a lot of exchange between Java and the OS like in I/O (both disk and network) heavy applications.
+        Java's solution to this is to allow programmers to request <code class="literal">ByteBuffer</code>s from so called direct memory.
+        This is an opaque structure that <span class="emphasis"><em>might</em></span> have an underlying implementation that makes it efficient to interact with the OS.
+        Unfortunately, the GC is not good at tracking direct memory and in general it is inadvisable to use direct memory for regular objects.
+      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Usage"></a>9.11.3.&#160;Memory Usage in the Broker</h3></div></div></div><p>
+      This section lists some note worthy users of memory within the broker and where possible lists their usage of heap and direct memory.
+      Note that to ensure smooth performance some heap memory should remain unused by the application and be reserved for the JVM to do house keeping and garbage collection.
+      <a class="link" href="https://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbCacheSize.html" target="_top">Some guides</a> advise to reserve up to 30% of heap memory for the JVM.
+    </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6498"></a>;Broker</h4></div></div></div><p>
+        The broker itself uses a moderate amount of heap memory (&#8776;15 MB).
+        However, each connection and session comes with a heap overhead of about 17 kB and 15 kB respectively.
+        In addition, each connection reserves 512 kB direct memory for network I/O.
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6503"></a>;Virtual Hosts</h4></div></div></div><p>
+        The amount of memory a Virtual Host uses depends on its type.
+        For a JSON Virtual Host Node with a BDB Virtual Host the heap memory usage is approximately 2 MB.
+        However, each BDB Virtual Hosts has a mandatory cache in heap memory which has an impact on performance.
+        See <a class="link" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Usage-BDB" title=";Message Store">below</a> for more information.
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6511"></a>;Messages</h4></div></div></div><p>
+        Messages and their headers are kept in direct memory and have an additional overhead of approximately 1 kB heap memory each.
+        This means that most brokers will want to have more direct memory than heap memory.
+        When many small messages accumulate on the broker the 1 kB heap memory overhead can become a <a class="link" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Low-Memory-Heap" title=";Low on Heap Memory">limiting factor</a>.
+      </p><p>
+        When the broker is <a class="link" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Low-Memory-Direct" title=";Low on Direct Memory">running low on direct memory</a>
+        it will evict messages from memory and <a class="link" href="Java-Broker-Runtime-Flow-To-Disk.html" title="9.6.&#160;Flow to Disk">flow them to disk</a>.
+        For persistent messages this only means freeing the direct memory representation because they always have an on-disk representation to guard against unexpected failure (e.g., a power cut).
+        For transient messages this implies additional disk I/O.
+        After being flown to disk messages need to be re-read from disk before delivery.
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Memory-Usage-BDB"></a>;Message Store</h4></div></div></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e6530"></a>Berkeley DB (BDB)</h5></div></div></div><p>
+          The broker can use Oracle's BDB JE (BDB) as a message store to persist messages by writing them to a database.
+          BDB uses a mandatory cache for navigating and organising its database structure.
+          Sizing and tuning this cache is a topic of its own and would go beyond the scope of this guide.
+          Suffice to say that by default Qpid uses 5% of heap memory for BDB caches (each Virtual Host uses a separate cache) or 10 MB per BDB store, whichever is greater.
+          See the <a class="link" href="http://www.oracle.com/us/products/database/berkeley-db/je" target="_top">official webpage</a> especially <a class="link" href="http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbCacheSize.html" target="_top">this page</a> for more information.
+          For those interested, Qpid uses <a class="link" href="http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/CacheMode.html#EVICT_LN" target="_top">EVICT_LN</a> as its default JE cacheMode.
+        </p><p>
+          Note that due to licensing concerns Qpid does not ship the BDB JE jar files.
+        </p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e6546"></a>Derby</h5></div></div></div><p>
+          TODO
+        </p></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6551"></a>;HTTP Management</h4></div></div></div><p>
+        Qpid uses Jetty for the HTTP Management (both REST and Web Management Console).
+        When the management plugin is loaded it will allocate the memory it needs and should not require more memory during operation and can thus be largely ignored.
+      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Low-Memory"></a>9.11.4.&#160;Low Memory Conditions</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Memory-Low-Memory-Heap"></a>;Low on Heap Memory</h4></div></div></div><p>
+        When the broker runs low on heap memory performance will degrade because the JVM will trigger full garbage collection (GC) events in a struggle to free memory.
+        These full GC events are also called stop-the-world events as they completely halt the execution of the Java application.
+        Stop-the-world-events may take any where from a couple of milliseconds up to several minutes.
+        Should the heap memory demands rise even further the JVM will eventually throw an OutOfMemoryError which will cause the broker to shut down.
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Memory-Low-Memory-Direct"></a>;Low on Direct Memory</h4></div></div></div><p>
+        When the broker detects that it uses 40% of available direct memory it will start flowing incoming transient messages to disk and reading them back before delivery.
+        This will prevent the broker from running out of direct memory but may degrade performance by requiring disk I/O.
+      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Defaults"></a>9.11.5.&#160;Defaults</h3></div></div></div><p>
+      By default Qpid uses these settings:
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
+          0.5 GB heap memory
+        </li><li class="listitem">
+          1.5 GB direct memory
+        </li><li class="listitem">
+          5% of heap reserved for the JE cache.
+        </li><li class="listitem">
+          Start flow-to-disk at 40% direct memory utilisation.
+        </li></ul></div><p>
+      As an example, this would accommodate a broker with 50 connections, each serving 5 sessions, and each session having 1000 messages of 1 kB on queues in the broker.
+      This means a total of 250 concurrent sessions and a total of 250000 messages without flowing messages to disk.
+    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Memory-Tuning"></a>9.11.6.&#160;Memory Tuning the Broker</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6587"></a>;Java Tuning</h4></div></div></div><p>
+        Most of these options are implementation specific. It is assumed you are using Oracle Java 1.7 and Qpid v6.
+        </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
+            Heap and direct memory can be configured through the <a class="link" href="Java-Broker-Appendix-Environment-Variables.html#Java-Broker-Appendix-Environment-Variables-Qpid-Java-Mem"><code class="literal">QPID_JAVA_MEM</code> environment variable</a>.
+          </li></ul></div><p>
+      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6601"></a>;Qpid Tuning</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
+          The system property <code class="literal">qpid.broker.bdbTotalCacheSize</code> sets the total amount of heap memory (in bytes) allocated to BDB caches.
+        </li><li class="listitem">
+          The system property <code class="literal">broker.flowToDiskThreshold</code> sets the threshold (in bytes) for flowing transient messages to disk.
+          Should the broker use more than direct memory it will flow incoming messages to disk.
+          Should utilisation fall beneath the threshold it will stop flowing messages to disk.
+        </li></ul></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6615"></a>;Formulas</h4></div></div></div><p>
+        We developed a simple formula which estimates the <span class="emphasis"><em>minimum</em></span> memory usage of the broker under certain usage.
+        These are rough estimate so we strongly recommend testing your configuration extensively.
+        Also, if your machine has more memory available by all means use more memory as it can only improve the performance and stability of your broker.
+        However, remember that both heap and direct memory are served from your computer's physical memory so their sum should never exceed the physically available RAM (minus what other processes use).
+      </p><p>
+        </p><div class="informalequation"><span class="mathphrase">
+            memory<sub>heap</sub> = 15 MB + 15 kB * N<sub>sessions</sub> + 1.5 kB * N<sub>messages</sub> + 17 kB * N<sub>connections</sub>
+          </span></div><p>
+      </p><p>
+        </p><div class="informalequation"><span class="mathphrase">
+            memory<sub>direct</sub> = 2 MB + (200 B + averageSize<sub>msg</sub> *2)*  N<sub>messages</sub> + 1MB * N<sub>connections</sub>
+          </span></div><p>
+      </p><p>
+        Where <span class="mathphrase">N</span> denotes the total number of connections/sessions/messages on the broker. Furthermore, for direct memory only the messages that have not been flown to disk are relevant.
+      </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The formulae assume the worst case in terms of memory usage: persistent messages and TLS connections. Transient messages consume less heap memory than peristent and plain connections consume less direct memory than TLS
+          connections.
+        </p></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="d0e6667"></a>;Things to Consider</h4></div></div></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e6670"></a>Performance</h5></div></div></div><p>
+          Choosing a smaller direct memory size will lower the threshold for flowing transient messages to disk when messages accumulate on a queue.
+          This can have impact on performance in the transient case where otherwise no disk I/O would be involved.
+        </p><p>
+          Having too little heap memory will result in poor performance due to frequent garbage collection events. See <a class="xref" href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Low-Memory" title="9.11.4.&#160;Low Memory Conditions">Section&#160;9.11.4, &#8220;Low Memory Conditions&#8221;</a> for more details.
+        </p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="d0e6679"></a>OutOfMemoryError</h5></div></div></div><p>
+          Choosing too low heap memory can cause an OutOfMemoryError which will force the broker to shut down.
+          In this sense the available heap memory puts a hard limit on the number of messages you can have in the broker at the same time.
+        </p><p>
+          If the Java runs out of direct memory it also throws a OutOfMemoryError resulting the a broker shutdown.
+          Under normal circumstances this should not happen but needs to be considered when deviating from the default configuration, especially when changing the flowToDiskThreshold.
+        </p><p>
+          If you are sending very large messages you should accommodate for this by making sure you have enough direct memory.
+        </p></div></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime-Connection-Limit.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-High-Availability.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">9.10.&#160;Connection Limits&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;Chapter&#160;10.&#160;High Availability</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Message-Compression.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Message-Compression.html.in
new file mode 100644
index 0000000..7add0e1
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Message-Compression.html.in
@@ -0,0 +1,15 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.9.&#160;Message Compression</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Background-Recovery.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Connection-Limit.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Message-Compression"></a>9.9.&#160;Message Compression</h2></div></div></div><p>The Apache Qpid Broker for Java supports<a class="footnote" href="#ftn.d0e6382" id="d0e6382"><sup class="footnote">[13]</sup></a> message compression. This feature works in co-operation with Qpid
+  Clients implementing the same feature.</p><p>Once the feature is enabled (using Broker context variable
+   <span class="emphasis"><em>broker.messageCompressionEnabled</em></span>), the Broker will advertise support for the
+  message compression feature to the client at connection time. This allows clients to opt to turn
+  on message compression, allowing message payload sizes to be reduced.</p><p>If the Broker has connections from clients who have message compression enabled and others who
+  do not, it will internally, on-the-fly, decompress compressed messages when sending to clients
+  without support and conversely, compress uncomressed messages when sending to clients who do.</p><p>The Broker has a threshold below which it will not consider compressing a message, this is
+  controlled by Broker content variable
+   (<code class="literal">connection.messageCompressionThresholdSize</code>) and expresses a size in bytes.</p><p>This feature <span class="emphasis"><em>may</em></span> have a beneficial effect on performance by:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Reducing the number of bytes transmitted over the wire, both between Client and Broker, and
+    in the HA case, Broker to Broker, for replication purposes.</p></li><li class="listitem"><p>Reducing storage space when data is at rest within the Broker, both on disk and in
+    memory.</p></li></ul></div><p>Of course, compression and decompression is computationally expensive. Turning on the feature
+  may have a negative impact on CPU utilization on Broker and/or Client. Also for small messages
+  payloads, message compression may increase the message size. It is recommended to test the feature
+  with representative data.</p><div class="footnotes"><br /><hr style="width:100; text-align:left;margin-left: 0" /><div class="footnote" id="ftn.d0e6382"><p><a class="para" href="#d0e6382"><sup class="para">[13] </sup></a>Message compression is not yet supported for the 1.0
+    protocol.</p></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime-Background-Recovery.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Connection-Limit.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">9.8.&#160;Background Recovery&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.10.&#160;Connection Limits</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Producer-Transaction-Timeout.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Producer-Transaction-Timeout.html.in
new file mode 100644
index 0000000..fb47911
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime-Producer-Transaction-Timeout.html.in
@@ -0,0 +1,57 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.3.&#160;Producer Transaction Timeout</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Disk-Space-Management.html">Prev</a>&#160;</td><th align="center" width="60%">Chapter&#160;9.&#160;Runtime</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Handling-Undeliverable-Messages.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout"></a>9.3.&#160;Producer Transaction Timeout</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-GeneralInformation"></a>9.3.1.&#160;General Information</h3></div></div></div><p> The transaction timeout mechanism is used to control bro
 ker resources when clients
+   producing messages using transactional sessions hang or otherwise become unresponsive, or simply
+   begin a transaction and keep using it without ever calling <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/Session.html#commit" target="_top">Session#commit()</a>.</p><p>Users can choose to configure an idleWarn or openWarn threshold, after which the identified
+   transaction should be logged as a WARN level alert as well as (more importantly) an idleClose or
+   openClose threshold after which the transaction and the connection it applies to will be
+   closed.</p><p>This feature is particularly useful in environments where the owner of the broker does not
+   have full control over the implementation of clients, such as in a shared services
+   deployment.</p><p>The following section provide more details on this feature and its use.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Purpose"></a>9.3.2.&#160;Purpose</h3></div></div></div><p> This feature has been introduced to address the scenario where an open transaction on the
+   broker holds an open transaction on the persistent store. This can have undesirable consequences
+   if the store does not time out or close long-running transactions, such as with BDB. This can can
+   result in a rapid increase in disk usage size, bounded only by available space, due to growth of
+   the transaction log. </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Scope"></a>9.3.3.&#160;Scope</h3></div></div></div><p>Note that only <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/MessageProducer.html" target="_top">MessageProducer</a> clients will be affected by a transaction timeout, since store
+   transaction lifespan on a consumer only spans the execution of the call to Session#commit() and
+   there is no scope for a long-lived transaction to arise.</p><p>It is also important to note that the transaction timeout mechanism is purely a JMS
+   transaction timeout, and unrelated to any other timeouts in the Qpid client library and will have
+   no impact on any RDBMS your application may utilise.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Effect"></a>9.3.4.&#160;Effect</h3></div></div></div><p>Full details of configuration options are provided in the sections that follow. This section
+   gives a brief overview of what the Transaction Timeout feature can do.</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Effect-Broker-Side"></a>;Broker Logging and Connection Close</h4></div></div></div><p>When the openWarn or idleWarn specified threshold is exceeded, the broker will log a WARN
+    level alert with details of the connection and channel on which the threshold has been exceeded,
+    along with the age of the transaction.</p><p>When the openClose or idleClose specified threshold value is exceeded, the broker will
+    throw an exception back to the client connection via the <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/ExceptionListener.html" target="_top">ExceptionListener</a>, log the
+    action and then close the connection.</p><p>The example broker log output shown below is where the idleWarn threshold specified is
+    lower than the idleClose threshold and the broker therefore logs the idle transaction 3 times
+    before the close threshold is triggered and the connection closed out.</p><pre class="screen">CHN-1008 : Idle Transaction : 13,116 ms
+CHN-1008 : Idle Transaction : 14,116 ms
+CHN-1008 : Idle Transaction : 15,118 ms
+CHN-1003 : Close
+   </pre><p>The second example broker log output shown below illustrates the same mechanism operating
+    on an open transaction.</p><pre class="screen">
+CHN-1007 : Open Transaction : 12,406 ms
+CHN-1007 : Open Transaction : 13,406 ms
+CHN-1007 : Open Transaction : 14,406 ms
+CHN-1003 : Close
+   </pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Effect-Client-Side"></a>;Client Side Effect</h4></div></div></div><p>After a Close threshold has been exceeded, the trigger client will receive this exception
+    on its <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/ExceptionListener.html" target="_top">exception
+    listener</a>, prior to being disconnected:</p><code class="computeroutput">org.apache.qpid.AMQConnectionClosedException: Error: Idle transaction timed out
+    [error code 506: resource error]</code><p>Any later attempt to use the connection will result in this exception being thrown:</p><pre class="screen">Producer: Caught an Exception: javax.jms.IllegalStateException: Object org.apache.qpid.client.AMQSession_0_8@129b0e1 has been closed
+    javax.jms.IllegalStateException: Object org.apache.qpid.client.AMQSession_0_8@129b0e1 has been closed
+    at org.apache.qpid.client.Closeable.checkNotClosed(Closeable.java:70)
+    at org.apache.qpid.client.AMQSession.checkNotClosed(AMQSession.java:555)
+    at org.apache.qpid.client.AMQSession.createBytesMessage(AMQSession.java:573)
+   </pre><p>Thus clients must be able to handle this case successfully, reconnecting where required and
+    registering an exception listener on all connections. This is critical, and must be communicated
+    to client applications by any broker owner switching on transaction timeouts.</p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Configuration"></a>9.3.5.&#160;Configuration</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Producer-Transaction-Timeout-Configuration-Overview"></a>;Configuration</h4></div></div></div><p>The transaction timeouts can be specified when a new virtualhost is created or an exiting
+    virtualhost is edited.</p><p>We would recommend that only warnings are configured at first, which should allow broker
+    administrators to obtain an idea of the distribution of transaction lengths on their systems,
+    and configure production settings appropriately for both warning and closure. Ideally
+    establishing thresholds should be achieved in a representative UAT environment, with clients and
+    broker running, prior to any production deployment.</p><p>It is impossible to give suggested values, due to the large variation in usage depending on
+    the applications using a broker. However, clearly transactions should not span the expected
+    lifetime of any client application as this would indicate a hung client.</p><p>When configuring warning and closure timeouts, it should be noted that these only apply to
+    message producers that are connected to the broker, but that a timeout will cause the connection
+    to be closed - this disconnecting all producers and consumers created on that connection.</p><p>This should not be an issue for environments using Mule or Spring, where connection
+    factories can be configured appropriately to manage a single MessageProducer object per JMS
+    Session and Connection. Clients that use the JMS API directly should be aware that sessions
+    managing both consumers and producers, or multiple producers, will be affected by a single
+    producer hanging or leaving a transaction idle or open, and closed, and must take appropriate
+    action to handle that scenario.</p></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Runtime-Disk-Space-Management.html">Prev</a>&#160;</td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Handling-Undeliverable-Messages.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">9.2.&#160;Disk Space Management&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.4.&#160;Handing Undeliverable Messages</td></tr></table></div></div>
\ No newline at end of file

diff --git a/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime.html.in b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime.html.in
new file mode 100644
index 0000000..2b6ea92
--- /dev/null
+++ b/input/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Runtime.html.in
@@ -0,0 +1,95 @@
+<div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter&#160;9.&#160;Runtime</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Security-Configuration-Encryption.html">Prev</a>&#160;</td><th align="center" width="60%">&#160;</th><td align="right" width="20%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Disk-Space-Management.html">Next</a></td></tr></table><hr /></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Java-Broker-Runtime"></a>Chapter&#160;9.&#160;Runtime</h1></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="section"><a href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging">9.1. Logging</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-Concepts">9.1.1. Concepts</a></span></dt><dt><span class="section"><a href="
 Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-Default-Configuration">9.1.2. Default Configuration</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-Loggers">9.1.3. Loggers</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-InclusionRules">9.1.4. Inclusion Rules</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-Management">9.1.5. Logging Management</a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Disk-Space-Management.html">9.2. Disk Space Management</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime-Disk-Space-Management.html#Qpid-Producer-Flow-Control">9.2.1. Producer Flow Control</a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html">9.3. Producer Transaction Timeout</a></span></dt><dd><dl><dt><span cla
 ss="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html#Java-Broker-Runtime-Producer-Transaction-Timeout-GeneralInformation">9.3.1. General Information</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html#Java-Broker-Runtime-Producer-Transaction-Timeout-Purpose">9.3.2. Purpose</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html#Java-Broker-Runtime-Producer-Transaction-Timeout-Scope">9.3.3. Scope</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html#Java-Broker-Runtime-Producer-Transaction-Timeout-Effect">9.3.4. Effect</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Producer-Transaction-Timeout.html#Java-Broker-Runtime-Producer-Transaction-Timeout-Configuration">9.3.5. Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Handling-Undeliverable-Messages
 .html">9.4. Handing Undeliverable Messages</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime-Handling-Undeliverable-Messages.html#Java-Broker-Runtime-Handling-Undeliverable-Messages-Introduction">9.4.1. Introduction</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Handling-Undeliverable-Messages.html#Java-Broker-Runtime-Handling-Undeliverable-Messages-Maximum-Delivery-Count">9.4.2. Maximum Delivery Count</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Handling-Undeliverable-Messages.html#Java-Broker-Runtime-Handling-Undeliverable-Messages-Dead-Letter-Queues">9.4.3. Dead Letter Queues (DLQ)</a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Close-Connection-When-No-Route.html">9.5. Closing client connections on unroutable mandatory messages</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime-Close-Connection-When-No-Route.html#Java-Broker-Runtime-Close-Connect
 ion-When-No-Route-Summary">9.5.1. Summary</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Close-Connection-When-No-Route.html#Java-Broker-Runtime-Close-Connection-When-No-Route-Configuration">9.5.2. Configuring <span class="emphasis"><em>closeWhenNoRoute</em></span></a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Flow-To-Disk.html">9.6. Flow to Disk</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Consumers.html">9.7. Consumers</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime-Consumers.html#Java-Broker-Runtime-Consumers-Prioirty">9.7.1. Priority</a></span></dt></dl></dd><dt><span class="section"><a href="Java-Broker-Runtime-Background-Recovery.html">9.8. Background Recovery</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Message-Compression.html">9.9. Message Compression</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Connection-Limit.ht
 ml">9.10. Connection Limits</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html">9.11. Memory</a></span></dt><dd><dl><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Introduction">9.11.1. Introduction</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Types">9.11.2. Types of Memory</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Usage">9.11.3. Memory Usage in the Broker</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Low-Memory">9.11.4. Low Memory Conditions</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Defaults">9.11.5. Defaults</a></span></dt><dt><span class="section"><a href="Java-Broker-Runtime-Memory.html#Java-Broker-Runtime-Memory-Tuning">9.11.6. Memory Tuning the 
 Broker</a></span></dt></dl></dd></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Java-Broker-Runtime-Logging"></a>9.1.&#160;Logging</h2></div></div></div><p>This section describes the flexible logging capabilities of the Apache Qpid Broker for Java.</p><p>
+    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The Broker is capable of sending logging events to a variety of destinations including
+          plain files, remote syslog daemons, and an in-memory buffer (viewable from Management).
+          The system is also open for extension meaning it is possible to produce a plugin to log to
+          a bespoke destination.</p></li><li class="listitem"><p>Logging can be dynamically configured at runtime. For instance, it is possible to
+          temporarily increase the logging verbosity of the system whilst a problem is investigated
+          and then revert later, all without the need to restart the Broker.</p></li><li class="listitem"><p>Virtualhosts can be configured to generate their own separate log, and the Broker is
+          capable of generating a log either inclusive or exclusive of virtualhost events.</p></li><li class="listitem"><p>Logs are accessible over Management, removing the need for those operating the Broker
+          to have shell level access.</p></li></ul></div><p>
+  </p><p>In the remainder of this section you will first find a description of the concepts used in
+    the logging subsystem. Next, you find a description of the default configuration. The section
+    then concludes with a in-depth description of the loggers themselves and how they may be
+    configured.</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Logging-Concepts"></a>9.1.1.&#160;Concepts</h3></div></div></div><p>The logging subsystem uses two concepts:</p><p>
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>A <span class="emphasis"><em>Logger</em></span> is responsible for production of a log. The Broker
+            ships a variety of loggers, for instance, a file logger, which is capable of writing a
+            log file to the file system, a Syslog Logger capable of writing to a remote syslog
+            daemon and console logger capable of writing to stdout or stderr.</p><p>Loggers are attached at two points within the Broker Model; the Broker itself and
+            the virtualhosts. Loggers attached at the Broker can capture log events for the system
+            as a whole, or can exclude events related to virtualhosts.</p><p>Loggers attached to a virtualhost capture log events relating to that virtualhost
+            only.</p><p>The Broker and virtualhosts can have zero or more Loggers. If no loggers are
+            configured, no logging is generated at all.</p></li><li class="listitem"><p><span class="emphasis"><em>Inclusion rules</em></span> govern what appears within a log. Inclusion
+            rules are associated with Loggers. This means it is possible for different Loggers to
+            have different contents.</p><p>A Logger with no inclusion rules will produce an empty log.</p></li></ul></div><p>
+    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Logging-Default-Configuration"></a>9.1.2.&#160;Default Configuration</h3></div></div></div><p>The default configuration is designed to be suitable for use without change in small
+      production environments. It has the following characteristics:</p><p>
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The Broker generates a single log file <code class="literal">qpid.log</code>. This logfile is
+            rolled automatically when the file reaches 100MB. A maximum history of one file is
+            retained. On restart the the log will be appended to.</p><p>The log contains: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>All operational logging events. See <a class="xref" href="Java-Broker-Appendix-Operation-Logging.html" title="Appendix&#160;C.&#160;Operational Logging">Appendix&#160;C, <em>Operational Logging</em></a>.</p></li><li class="listitem"><p>Log events from Qpid itself deemed informational or
+                higher.</p></li><li class="listitem"><p>Log events from Qpid's dependencies (such as Derby or Jetty) that are
+                  deemed warning or higher.</p></li></ul></div><p>
+          </p><p>The default location for the log file is
+              <code class="literal">${QPID_WORK}/log/qpid.log</code>.</p></li><li class="listitem"><p>The Broker also caches the last 4096 log events in a memory cache. By default, the
+            memory logger logs the same things the file logger does.</p></li></ul></div><p>
+    </p><p>The configuration can be customised at runtime using Management. This makes it possible to
+      investigate unusual conditions <span class="emphasis"><em>without</em></span> the need to restart the Broker.
+      For instance, you may alter the logging level so that a verbose log is produced whilst an
+      investigation is in progress and revert the setting later, all without the need to restart the
+      Broker.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Logging-Loggers"></a>9.1.3.&#160;Loggers</h3></div></div></div><p>Loggers are responsible for the writing of a log. The log includes log events that match a
+      Logger's inclusion rules.</p><p>Loggers are associated with either the Broker or a virtualhost. Virtualhost loggers write
+      only log events related to that virtualhost. Broker Loggers write log events from the Broker
+      as a whole. Optionally a Broker Logger can be configured to exclude log events coming from
+      virtualhosts. These abilities can be usefully exploited together in managed service scenarios
+      to produce separate logs for separate user groups.</p><p>Loggers can be added or removed at runtime, without restarting the Broker. However changes
+      to a Logger's configuration such as filenames and rolling options don't take effect until the
+      next restart. Changes to a Logger's inclusion rules take effect immediately.</p><p>All loggers allow the log event layout to be customised. Loggers understand <a class="link" href="http://logback.qos.ch/manual/layouts.html#ClassicPatternLayout" target="_top"> Logback Classic
+        Pattern Layouts</a>. </p><p>The following sections describes each Logger implementation in detail.</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Logging-Loggers-FileLogger"></a>;FileLogger</h4></div></div></div><p>A <span class="emphasis"><em>FileLogger</em></span> - writes a log file to the filesystem. The name and
+        location of the log file, the rolling configuration, and compression options can be
+        configured.</p><p>The <span class="emphasis"><em>roll daily</em></span> option, if enabled, will cause the log file will be
+        rolled at midnight local time. The rolled over file will have a suffix in the form
+          <code class="literal">yyyy-mm-dd</code>. In roll daily mode, <span class="emphasis"><em>maximum number of rolled
+          files</em></span> controls the maximum number of <span class="emphasis"><em>days</em></span> to be retained.
+        Older files will be deleted.</p><p>The <span class="emphasis"><em>maximum file size</em></span> option limits the size of any one log file.
+        Once a log file reaches the given size, it will be rolled. The rolled over file will have
+        the numeric suffix, beginning at <code class="literal">1</code>. If the log file rolls again, first
+        the existing file with the suffix <code class="literal">.1</code> is renamed to <code class="literal">.2</code>
+        and so forth. If roll daily is not in use, <span class="emphasis"><em>maximum number of rolled
+          files</em></span> governs the number of rolled <span class="emphasis"><em>files</em></span> that will be
+        retained.</p><p><span class="emphasis"><em>Roll on restart</em></span> governs whether the log file is rolled when the
+        Broker is restarted. If not ticked, the Broker will append to the existing log file until it
+        needs to be rolled.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Logging-Loggers-ConsoleLogger"></a>;ConsoleLogger</h4></div></div></div><p><span class="emphasis"><em>ConsoleLogger</em></span> - writes a log file standard out or standard
+        error.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Logging-Loggers-SyslogLogger"></a>;SyslogLogger</h4></div></div></div><p><span class="emphasis"><em>SyslogLogger</em></span> - writes a log file to a syslog daemon using the
+          <code class="literal">USER</code> facility. The hostname and port number of the syslog daemon can be
+        configured.</p><p>Log entries can be prefixed with a string. This string defaults to include the word
+          <code class="literal">Qpid</code> and the name of the Broker or virtualhost. This serves to
+        distinguish the logging generated by this Qpid instance, from other Qpid instances, or other
+        applications using the <code class="literal">USER</code>.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Logging-Loggers-MemoryLogger"></a>;MemoryLogger</h4></div></div></div><p><span class="emphasis"><em>MemoryLogger</em></span> - writes a log file to a circular in-memory buffer. By
+        default the circular buffer holds the last 4096 log events. The contents of the buffer can
+        be viewed via Management. See <a class="xref" href="Java-Broker-Runtime.html#Java-Broker-Runtime-Logging-Management-MemoryLogger" title="Figure&#160;9.3.&#160;Viewing a memory logger">Figure&#160;9.3, &#8220;Viewing a memory logger&#8221;</a></p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Logging-InclusionRules"></a>9.1.4.&#160;Inclusion Rules</h3></div></div></div><p>A <span class="emphasis"><em>Logger</em></span> has one or more <span class="emphasis"><em>inclusion rules</em></span>. These
+      govern what appears in the log. A Logger with no inclusion rules will log nothing.</p><p>Inclusion rules can be added, removed or changed at runtime. Changes take place
+      immediately.</p><p>
+      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The <span class="emphasis"><em>Name And Level</em></span> inclusion rule accepts log events that match
+            a given <span class="emphasis"><em>log event source name</em></span> and have a level that equals or
+            exceeds the specified value.</p><p>The log event source name refers to the fully qualified class name from which the
+            event originates. These names permit a trailing wild card <code class="literal">.*</code>. For
+            instance a source name of <code class="literal">org.apache.qpid.*</code> will match all events
+            from classes in the package <code class="literal">org.apache.qpid</code> and any sub packages
+            beneath.</p><p>The <span class="emphasis"><em>Level</em></span> governs the level of the events that will be included
+            in the log. It may take one of the following values: ERROR, WARN, INFO, DEBUG, TRACE
+            where ERROR is considered the highest and TRACE the lowest. In addition, there are two
+            special values: OFF and ALL, the former excludes all log events whereas the latter will
+            include everything. When considering whether a logging event should be included in the
+            log, the logging event must have a level that matches that of the inclusion rule or be
+            higher, otherwise the log event will not appear in the log.</p></li></ul></div><p>
+    </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Logging-Management"></a>9.1.5.&#160;Logging Management</h3></div></div></div><p>The logging subsystem can be completely managed from the Web Management Console or the
+      REST API. You can: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Add, remove, or change the configuration of Loggers.</p></li><li class="listitem"><p>Add, remove, or change the Inclusion Rules.</p></li><li class="listitem"><p>For FileLoggers, download the log file and rolled log files associated with
+            the Logger.</p></li><li class="listitem"><p>For MemoryLoggers, view the last <code class="literal">n</code> log
+          events</p></li></ul></div><p>
+    </p><p> The figure that follows shows a FileLogger. The attributes area shows the configuration
+      of the Logger. The inclusion rule table shows the rules that are associated with the Logger.
+      The area towards the bottom of the tab allows the log files to be downloaded to the browser.
+        </p><div class="figure"><a id="Java-Broker-Runtime-Logging-Management-FileLogger"></a><p class="title"><strong>Figure&#160;9.1.&#160;Viewing a file logger</strong></p><div class="figure-contents"><div class="mediaobject"><table border="0" style="cellpadding: 0; cellspacing: 0;" summary="manufactured viewport for HTML img" width="900"><tr><td><img alt="Viewing a file logger" src="images/Management-Web-Logging-FileLogger.png" width="900" /></td></tr></table></div></div></div><p><br class="figure-break" />
+    </p><p> The figure below shows the editing of the level of an inclusion rule. </p><div class="figure"><a id="Java-Broker-Runtime-Logging-Management-InclusionRule"></a><p class="title"><strong>Figure&#160;9.2.&#160;Editing an inclusion rule</strong></p><div class="figure-contents"><div class="mediaobject"><table border="0" style="cellpadding: 0; cellspacing: 0;" summary="manufactured viewport for HTML img" width="900"><tr><td><img alt="Editing an inclusion rule" src="images/Management-Web-Logging-InclusionRule.png" width="900" /></td></tr></table></div></div></div><p><br class="figure-break" />
+    </p><p> The figure below shows a Memory Logger. Note that the Memory Logger provides access to
+      the cached message via the viewer towards the bottom on the tab. </p><div class="figure"><a id="Java-Broker-Runtime-Logging-Management-MemoryLogger"></a><p class="title"><strong>Figure&#160;9.3.&#160;Viewing a memory logger</strong></p><div class="figure-contents"><div class="mediaobject"><table border="0" style="cellpadding: 0; cellspacing: 0;" summary="manufactured viewport for HTML img" width="900"><tr><td><img alt="Viewing a memory logger" src="images/Management-Web-Logging-MemoryLogger.png" width="900" /></td></tr></table></div></div></div><p><br class="figure-break" />
+    </p></div></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="Java-Broker-Security-Configuration-Encryption.html">Prev</a>&#160;</td><td align="center" width="20%">&#160;</td><td align="right" width="40%">&#160;<a accesskey="n" href="Java-Broker-Runtime-Disk-Space-Management.html">Next</a></td></tr><tr><td align="left" valign="top" width="40%">8.4.&#160;Configuration Encryption&#160;</td><td align="center" width="20%"><a accesskey="h" href="AMQP-Messaging-Broker-Java-Book.html">Home</a></td><td align="right" valign="top" width="40%">&#160;9.2.&#160;Disk Space Management</td></tr></table></div></div>
\ No newline at end of file

To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org

View raw message