| <div class="docbook"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">9.3. Transaction Timeout</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="Java-Broker-Runtime-Disk-Space-Management.html">Prev</a> </td><th align="center" width="60%">Chapter 9. Runtime</th><td align="right" width="20%"> <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-Transaction-Timeout"></a>9.3. Transaction Timeout</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Transaction-Timeout-GeneralInformation"></a>9.3.1. General Information</h3></div></div></div><p> The transaction timeout mechanism is used to control broker resources when clients |
| using transactions hang, become unresponsive, or simply (due to programming error) |
| begin a transaction and keep using it without ever calling committing or rolling back.</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-Transaction-Timeout-Purpose"></a>9.3.2. 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-Transaction-Timeout-Effect"></a>9.3.3. 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-Transaction-Timeout-Effect-Broker-Side"></a>9.3.3.1. 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 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"> |
| CON-1011 : Idle Transaction : 13,116 ms |
| CON-1011 : Idle Transaction : 14,116 ms |
| CON-1011 : Idle Transaction : 15,118 ms |
| CON-1002 : Close : Idle transaction timed out |
| </pre><p>The second example broker log output shown below illustrates the same mechanism operating |
| on an open transaction.</p><pre class="screen"> |
| CON-1010 : Open Transaction : 12,406 ms |
| CON-1010 : Open Transaction : 13,406 ms |
| CON-1010 : Open Transaction : 14,406 ms |
| CON-1002 : Close : Open transaction timed out |
| </pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Transaction-Timeout-Effect-Client-Side"></a>9.3.3.2. Client Side Effect</h4></div></div></div><p>After a Close threshold has been exceeded, the Broker will close the client's connection. |
| The application must reconnect itself in order to continue work. If the |
| client is a JMS client, the application will be notified by the |
| <a class="link" href="http://docs.oracle.com/javaee/6/api/javax/jms/ExceptionListener.html" target="_top">exception |
| listener.</a></p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="Java-Broker-Runtime-Transaction-Timeout-Configuration"></a>9.3.4. Configuration</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="Java-Broker-Runtime-Transaction-Timeout-Configuration-Overview"></a>9.3.4.1. 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 closure timeouts, it should be noted that a timeout on any producer |
| or consumer will cause the connection to be closed - this disconnecting all producers and consumers |
| created on that connection.</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> </td><td align="center" width="20%"><a accesskey="u" href="Java-Broker-Runtime.html">Up</a></td><td align="right" width="40%"> <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. Disk Space Management </td><td align="center" width="20%"><a accesskey="h" href="Apache-Qpid-Broker-J-Book.html">Home</a></td><td align="right" valign="top" width="40%"> 9.4. Handing Undeliverable Messages</td></tr></table></div></div> |
