svn commit: r833916 - in /websites/production/cxf/content: cache/docs.pageCache docs/asynchronous-client-http-transport.html

[bu...@apache.org]

Author: buildbot
Date: Wed Oct  3 17:47:26 2012
New Revision: 833916

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/asynchronous-client-http-transport.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/asynchronous-client-http-transport.html
==============================================================================
--- websites/production/cxf/content/docs/asynchronous-client-http-transport.html (original)
+++ websites/production/cxf/content/docs/asynchronous-client-http-transport.html Wed Oct  3 17:47:26 2012
@@ -129,7 +129,7 @@ Apache CXF -- Asynchronous Client HTTP T
 
 <p>CXF also has an HTTP client transport that is based on the <a shape="rect" class="external-link" href="http://hc.apache.org/httpcomponents-asyncclient-dev/index.html">Apache HTTP Components HttpAsyncClient</a> library.   The HttpAsyncClient library uses a non-blocking IO model.  This allows many more requests to be outstanding without consume extra background threads.   It also allows greater control over things like Keep-Alive handling which is very difficult or impossible with the HttpURLConnection based transport.   However, the non-blocking model does not perform quite as well as the blocking model for pure synchronous request/response transactions.</p>
 
-<p>By default, if the cxf-rt-transports-http-hc module is found on the classpath, CXF will use the HttpAsyncClient based implementation for any Async calls, but will continue to use the HttpURLConnection based transport for synchronous calls.   This allows a good balance of performance for the common synchronous cases with scalability for the asynchronous cases.  However, using a contextual property of "use.async.http.conduit" and set to true/false, you can control whether the async or blocking version is used.</p>
+<p>By default, if the cxf-rt-transports-http-hc module is found on the classpath, CXF will use the HttpAsyncClient based implementation for any Async calls, but will continue to use the HttpURLConnection based transport for synchronous calls.   This allows a good balance of performance for the common synchronous cases with scalability for the asynchronous cases.  However, using a contextual property of "use.async.http.conduit" and set to true/false, you can control whether the async or blocking version is used.  If "true", the HttpAsyncClient will be used even for synchronous calls, if "false", asynchronous calls will rely on the traditional method of using HTTPURLConnection along with a work queue to mimic the asynchronocity.</p>
 
 <h3><a shape="rect" name="AsynchronousClientHTTPTransport-SettingCredentials"></a>Setting Credentials</h3>
 
@@ -159,10 +159,10 @@ bp.getRequestContext().put(Credentials.c
 <h3><a shape="rect" name="AsynchronousClientHTTPTransport-Configuration"></a>Configuration </h3>
 <p>The Asynchronous HTTP Transport has several options that can set using Bus properties or via the OSGi configuration services to control various aspects of the underlying Apache HTTP Components HttpAsyncClient objects.</p>
 
-<p>Settings related to the underlying TCP socket:</p>
+<p>Settings related to the underlying TCP socket (see <a shape="rect" class="external-link" href="http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html" rel="nofollow">java.net.Socket</a> for a definition of these values):</p>
 
 <div class="table-wrap">
-<table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.TCP_NODELAY </td><td colspan="1" rowspan="1" class="confluenceTd"> The TCP_NODELAY for the socket.   Defaults to true.</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_KEEPALIVE</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_LINGER</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_TIMEOUT</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td></tr></tbody></table>
+<table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.TCP_NODELAY (Default true)</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_KEEPALIVE</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_LINGER</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.SO_TIMEOUT</td></tr></tbody></table>
 </div>
 
 
@@ -181,7 +181,7 @@ bp.getRequestContext().put(Credentials.c
 
 <p>Setting to control which conduit is used</p>
 <div class="table-wrap">
-<table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.usePolicy</td><td colspan="1" rowspan="1" class="confluenceTd"> ALWAYS, ASYNC_ONLY, NEVER.   </td></tr></tbody></table>
+<table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.cxf.transport.http.async.usePolicy</td><td colspan="1" rowspan="1" class="confluenceTd"> ALWAYS, ASYNC_ONLY, NEVER.   </td><td colspan="1" rowspan="1" class="confluenceTd"> Similar in meaning to the "use.async.http.conduit" context property described above.  Whether to use the HttpAsyncClient: ALWAYS for both synchronous and asynchronous calls, ASYNC_ONLY (default) for asynchronous calls only, NEVER will use HTTPURLConnection for both types of calls.</td></tr></tbody></table>
 </div>
 </div>
            </div>