Author: jmesnil Date: 2009-12-04 05:58:54 -0500 (Fri, 04 Dec 2009) New Revision: 8547 Modified: trunk/docs/user-manual/en/configuration-index.xml trunk/docs/user-manual/en/connection-ttl.xml Log: documentation update * updated default value and description for async-connection-execution-enabled configuration Modified: trunk/docs/user-manual/en/configuration-index.xml =================================================================== --- trunk/docs/user-manual/en/configuration-index.xml 2009-12-04 09:43:37 UTC (rev 8546) +++ trunk/docs/user-manual/en/configuration-index.xml 2009-12-04 10:58:54 UTC (rev 8547) @@ -369,7 +369,7 @@ <entry>Should incoming packets on the server be handed off to a thread from the thread pool for processing or should they be handled on the remoting thread?</entry> - <entry>true</entry> + <entry>false</entry> </row> <row> <entry><link linkend="transaction-config" Modified: trunk/docs/user-manual/en/connection-ttl.xml =================================================================== --- trunk/docs/user-manual/en/connection-ttl.xml 2009-12-04 09:43:37 UTC (rev 8546) +++ trunk/docs/user-manual/en/connection-ttl.xml 2009-12-04 10:58:54 UTC (rev 8547) @@ -158,20 +158,14 @@ </section> <section id="connection-ttl.async-connection-execution"> <title>Configuring Asynchronous Connection Execution</title> - <para>By default, as packets are received by on the server side, they are handed off to a - thread from the internal thread pool for processing, rather than processing them on the - remoting thread.</para> - <para>This prevents remoting threads being tied up for too long, especially if the operation - takes a significant time to complete. It's dangerous for remoting threads to be tied up - for too long, since then they might not be able to handle pings from the client, - resulting in reply pings being sent back to the client late and the client erroneously - thinking a problem has happened on the connection.</para> - <para>Processing operations asynchronously on another thread does however add a little more - latency, so we allow this to be configured using the parameter <literal + <para>By default, packets received on the server side are handed off by the remoting thread + for processing.</para> + <para>It is possible instead to use a thread from a thread pool to handle the packents so + that the remoting thread is not tied up for too long. However, please note that processing + operations asynchronously on another thread adds a little more + latency. To enable asynchronous connection executin, set the parameter <literal - >hornetq-configuration.xml</literal>. The default value for this parameter is - <literal>true</literal>.</para> - <para>If you do set this parameter to <literal>false</literal> please do so with - caution.</para> + >hornetq-configuration.xml</literal> to <literal>true</literal> (default value is + <literal>false</literal>).</para> </section> </chapter>