[jboss-cvs] JBossRemoting/docs/guide/en ...
Ron Sigal
ron_sigal at yahoo.com
Mon Mar 12 21:55:54 EDT 2007
User: rsigal
Date: 07/03/12 21:55:54
Modified: docs/guide/en Tag: remoting_2_x chap5.xml
Log:
JBREM-298, JBREM-598, JBREM-605, JBREM-634, JBREM-650, JBREM-657: Added sections on (1) socket creation listeners; (2) per invocation timeouts; (3) callback acknowledgements; (4) bisocket transport; (5) quick disconnects. (6) Reorganized callback section.
Revision Changes Path
No revision
No revision
1.12.2.8 +657 -7 JBossRemoting/docs/guide/en/chap5.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: chap5.xml
===================================================================
RCS file: /cvsroot/jboss/JBossRemoting/docs/guide/en/chap5.xml,v
retrieving revision 1.12.2.7
retrieving revision 1.12.2.8
diff -u -b -r1.12.2.7 -r1.12.2.8
--- chap5.xml 7 Mar 2007 09:08:29 -0000 1.12.2.7
+++ chap5.xml 13 Mar 2007 01:55:54 -0000 1.12.2.8
@@ -11,7 +11,8 @@
the remoting distribution that shows full examples of all the remoting
configurations.</para>
- <section>
+ <section id="section-configuration"
+ xreflabel="General transport configuration">
<title>General transport configuration</title>
<para>Remoting offers a variety of ways of configuring transports on the
@@ -19,7 +20,7 @@
rest of the chapter elaborates the material presented here. For easy
reference the configuration parameters discussed throughout the chapter
are gathered together at the end of the chapter in section <xref
- linkend="section-configuration" /></para>
+ linkend="section-configuration-by-properties" /></para>
<section>
<title>Server side configuration</title>
@@ -103,7 +104,7 @@
<code>ServerInvoker.SERVER_SOCKET_FACTORY</code> is
"serverSocketFactory". These configuration map keys are discussed
throughout the chapter and accumulated in section <xref
- linkend="section-configuration" />. Also, server socket factory
+ linkend="section-configuration-by-properties" />. Also, server socket factory
configuration is covered in <xref
linkend="section-socket-factories" />.</para>
@@ -311,6 +312,27 @@
<para>Note: The value for the 'path' attribute should NOT start or end
with a / (slash).</para>
</section>
+
+ <section>
+ <title>Callback client configuration</title>
+
+ <para>
+ Remoting supports asynchronous computation and delivery of results
+ through a callback mechanism, as described in Section <xref
+ linkend="section-callbacks"/>. Callbacks are sent from the server side
+ to the client side on a callback connection which is the reverse of
+ the usual client to server connection. That is, a client invoker on
+ the server side communicates with a server invoker on the client side
+ (in the case of push callbacks - again, see Section <xref
+ linkend="section-callbacks"/>). When a callback connection is created,
+ all of the configuration information passed to the server side
+ <classname>Connector</classname> is passed on to the server side
+ callback client invoker. It follows that callback client invokers are
+ configured by way of the server side
+ <classname>Connector</classname>.
+ </para>
+
+ </section>
</section>
<section>
@@ -366,7 +388,7 @@
"timeout", and the value of <code>Remoting.CUSTOM_SOCKET_FACTORY</code>
is "customSocketFactory". These configuration map keys are discussed
throughout the chapter and accumulated in section <xref
- linkend="section-configuration" />. Also, socket factory configuration
+ linkend="section-configuration-by-properties" />. Also, socket factory configuration
is covered in <xref linkend="section-socket-factories" />.</para>
<para>Finally, a third programmatic option is available for those
@@ -1213,7 +1235,8 @@
allowed for Tomcat can be configured for the remoting HTTP server
invoker. For more information on the configuration attributes available
for the Tomcat connectors, please refer to <ulink
- url="http://tomcat.apache.org/tomcat-5.5-doc/config/http.htm">http://tomcat.apache.org/tomcat-5.5-doc/config/http.htm</ulink>.
+ url="http://tomcat.apache.org/tomcat-5.5-doc/config/http.html">http://tomcat.apache.org/tomcat-5.5-doc/config/http.html</ulink>.
+ http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
<!--<link linkend="???">http://tomcat.apache.org/tomcat-5.5-doc/config/http.html</link>-->
So for example, if wanted to set the maximum number of threads to be
used to accept incoming http requests, would use the 'maxThreads'
@@ -2505,6 +2528,350 @@
when configuring a socket factory. See section <xref
linkend="section-socket-factories" /> for more information.</para>
</section>
+
+ <section>
+ <title>Bisocket invoker</title>
+
+ <para>
+ The <emphasis role="bold">bisocket transport</emphasis>, like the
+ multiplex transport, is a bidirectional transport that can function
+ in the presence of restrictions that would prevent a unidirectional
+ transport like socket or http from creating a server to client push callback
+ connection. (See Section <xref linkend="section-callbacks"/> for more
+ information about callbacks and bidirectional and unidirectional
+ transports.) For example, security restrictions could prevent the
+ application from opening a <classname>ServerSocket</classname> on the
+ client, or firewall restrictions could prevent the server from contacting a
+ <classname>ServerSocket</classname> even if it were possible to create
+ one.
+ </para>
+
+ <section>
+ <title>Overview</title>
+ <para>
+ The bisocket client and server invokers inherit most of their
+ functionality from the socket invokers, with the principal exception of
+ overriding a method in the client invoker called
+ <methodname>createSocket()</methodname>. If
+ the client invoker is on the client side, then
+ <methodname>createSocket()</methodname> simply calls the super
+ implementation. The heart of the bisocket transport is in handling the
+ case of creating a connection from a callback client invoker on the
+ server side to a callback server invoker on the client side, which is
+ mandated to occur without the use of a
+ <classname>ServerSocket</classname> on the client side. Whenever the
+ bisocket transport is informed by an application of its intention to use
+ push callbacks, the client side creates a secondary "control"
+ connection, and subsequently, whenever the callback client invoker needs
+ to create a connection to the callback server, it sends a request over
+ the control connection asking the client side to establish the
+ connection. The server side of the transport maintains a secondary
+ <classname>ServerSocket</classname> that accepts connection requests from
+ the client side, and whenever a socket is created it is passed to whichever
+ callback client invoker requested it. The client invoker, which
+ inherits the socket transport's connection pool management facility, adds
+ the new socket to its connection pool.
+ </para>
+
+ <para>
+ Note that if the control
+ connection were to fail, no new connections could be created for the
+ callback client invoker, and eventually callback transmission could come
+ to a halt. The client and server invokers work together, therefore, to
+ maintain a heartbeat on the control connection and to
+ recreate the control connection automatically should it fail. In
+ particular, the server side sends out ping messages on the control
+ connection, and the client side needs to receive a ping message within
+ some configured window in order to consider the connection to be
+ functional.
+ </para>
+
+ <para>
+ In addition to the configuration options inherited from the socket
+ transport, the bisocket transport may be configured with the following
+ parameters, which are defined as constants in the
+ <classname>org.jboss.remoting.transport.bisocket.Bisocket</classname>
+ class. A parameter can be configured on the server side by appending
+ it to the <classname>InvokerLocator</classname> or by adding it to the
+ configuration map passed to the <classname>Connector</classname>'s
+ constructor. On the client side, where all parameters are used by the
+ callback server invoker, there are several options for setting
+ parameter values. If the callback <classname>Connector</classname>
+ is created explicitly, then a parameter can be configured
+ by appending it to the callback <classname>Connector</classname>'s
+ <classname>InvokerLocator</classname> or
+ by adding it to the configuration map passed to the callback
+ <classname>Connector</classname>'s constructor. If the callback
+ <classname>Connector</classname> is created
+ implicitly by the <methodname>Client.addListener()</methodname> method,
+ then its configuration map is the union of the
+ <classname>Client</classname>'s configuration map and the
+ <code>metadata</code> map passed as a parameter to
+ <methodname>Client.addListener()</methodname>.
+ </para>
+
+
+ <para>
+ <emphasis role="bold">IS_CALLBACK_SERVER</emphasis> (actual value is
+ "isCallbackServer"): when a bisocket server invoker receives this
+ parameter with a value of true, it avoids the creation of a
+ <classname>ServerSocket</classname>. Therefore, IS_CALLBACK_SERVER
+ should be used on the client side for the creation of a callback
+ server. The default value is false.
+ </para>
+
+ <para>
+ <emphasis role="bold">PING_FREQUENCY</emphasis> (actual
+ value is "pingFrequency"): The server side uses this value
+ to determine the interval, in milliseconds, between pings that it will
+ send on the control connection. The client side uses this value to
+ calculate the window in which it must receive pings on the control
+ connection. In particular, the window is ping frequency * ping window factor.
+ See also the definition of PING_WINDOW_FACTOR. The default value is 5000.
+ </para>
+
+ <para>
+ <emphasis role="bold">PING_WINDOW_FACTOR</emphasis> (actual
+ value is "pingWindowFactor"): The client side uses this value to
+ calculate the window in which it must receive pings on the control
+ connection. In particular, the window is ping frequency * ping window factor.
+ See also the definition of PING_FREQUENCY. The default value is 2.
+ </para>
+ </section>
+
+ <section>
+ <title>Details</title>
+
+ <para>
+ Using the bisocket transport certainly does not require understanding
+ its implementation details, but some further information is presented
+ in this section for those who might be interested.
+ </para>
+
+ <para>
+ In the following discussion, the client side client invoker and the
+ server side server invoker will be referred to simply as "client
+ invoker" and "server invoker." The callback client invoker and
+ callback server invoker will be explicitly identified as such.
+ </para>
+
+ <para>
+ The following sequence of events occurs in the course of creating a
+ control connection. For simplicity it is assumed that the
+ <classname>Client</classname> and <classname>Connector</classname>
+ have already been created, and that the callback server is created
+ implicitly by the <classname>Client</classname>. These events are
+ illustrated in Figure 5.1.
+ </para>
+
+ <orderedlist>
+ <listitem>
+ The application calls <methodname>Client.addListener()</methodname>.
+ </listitem>
+
+ <listitem>
+ The <classname>Client</classname> creates a callback
+ <classname>Connector</classname> and the callback server invoker
+ registers itself in a static map.
+ </listitem>
+
+ <listitem>
+ The <classname>Client</classname> sends an "addListener" message
+ to the server invoker by way of the client invoker.
+ </listitem>
+
+ <listitem>
+ The client invoker intercepts the "addListener" message, which tells
+ it that a callback server is being created.
+ It retrieves the callback server invoker from the static map and
+ tells it to create a control connection for the callback
+ connection that is being constructed.
+ </listitem>
+
+ <listitem>
+ The callback server invoker sends an internal message to the server
+ invoker requesting the address and port of the secondary
+ <classname>ServerSocket</classname>
+ </listitem>
+
+ <listitem>
+ The callback server invoker connects to the secondary
+ <classname>ServerSocket</classname> to create a
+ <classname>Socket</classname> for the control connection. If it has
+ not already done so, the callback server invoker creates a
+ <classname>TimerTask</classname> which will monitor the state of all
+ of its control connections. (Note that if the callback
+ <classname>Connector</classname> is created explicitly, it could
+ have multiple <classname>InvokerCallbackHandler</classname>s
+ registered with it.)
+ </listitem>
+
+ <listitem>
+ On the server side, the <classname>Socket</classname> just created
+ by the secondary <classname>ServerSocket</classname> is stored in a
+ static map, awaiting the creation of the callback client invoker.
+ </listitem>
+
+ <listitem>
+ The client invoker transmits the "addListener" message to the
+ server invoker.
+ </listitem>
+
+ <listitem>
+ The server invoker creates a callback client invoker.
+ </listitem>
+
+ <listitem>
+ The callback client invoker retrieves the waiting socket and uses it
+ for the control connection.
+ </listitem>
+
+ <listitem>
+ The callback client invoker begins pinging on the control connection.
+ </listitem>
+ </orderedlist>
+
+ <figure>
+ <title>Creating a control connection.</title>
+ <graphic fileref="images/bisocket1.png"
+ width="765pt" depth="495"
+ contentwidth="765pt" contentdepth="445"
+ format="png" align="center"
+ />
+ </figure>
+
+ <para>
+ The following sequence of events occurs in the course of creating a
+ connection for the callback client invoker to use for sending
+ callbacks. It is illustrated in Figure 5.2.
+ </para>
+
+ <orderedlist>
+ <listitem>
+ The <classname>ServerInvocationHandler</classname> calls
+ <methodname>InvokerCallbackHandler.handleCallback()</methodname>.
+ </listitem>
+
+ <listitem>
+ The <classname>InvocationCallbackHandler</classname> calls
+ <methodname>invoke()</methodname> on the callback
+ <classname>Client</classname>.
+ </listitem>
+
+ <listitem>
+ The <classname>Client</classname> calls
+ <methodname>invoke()</methodname> on the callback client invoker.
+ </listitem>
+
+ <listitem>
+ If there are no connections in its connection pool, the callback
+ client invoker sends a message on the control connection asking the
+ callback server invoker to connect to the server side secondary
+ <classname>ServerSocket</classname>. It then waits for the
+ <classname>Socket</classname> to appear in a static map.
+ </listitem>
+
+ <listitem>
+ The callback server invoker receives the request and calls upon
+ either a <classname>Socket</classname> constructor or a
+ <classname>SocketFactory</classname> to create a new
+ <classname>Socket</classname>. It passes the new
+ <classname>Socket</classname> to a worker thread to process
+ subsequent callback invocations.
+ </listitem>
+
+ <listitem>
+ The secondary <classname>ServerSocket</classname> creates a new
+ <classname>Socket</classname>, which is placed in a static map.
+ </listitem>
+
+ <listitem>
+ The callback client invoker retrieves the new
+ <classname>Socket</classname>
+ </listitem>
+
+ <listitem>
+ The callback client uses the new <classname>Socket</classname> to
+ transmit a callback, and adds the new connection to its connection
+ pool for later use.
+ </listitem>
+ </orderedlist>
+
+ <figure>
+ <title>Creating a callback connection.</title>
+ <graphic fileref="images/bisocket2.png"
+ width="765pt" depth="495"
+ contentwidth="765pt" contentdepth="445"
+ format="png" align="center"
+ />
+ </figure>
+
+ <para>
+ The following sequence of events occurs when a control connection
+ fails. It is illustrated in Figure 5.3.
+ </para>
+
+ <orderedlist>
+ <listitem>
+ The callback server invoker notices that a ping has not been
+ received during the control connection's current window.
+ </listitem>
+
+ <listitem>
+ The callback server invoker reacquires the host and port of the
+ secondary <classname>ServerSocket</classname>, just in case it has
+ changed.
+ </listitem>
+
+ <listitem>
+ The callback server invoker calls on a <classname>Socket</classname>
+ constructor or <classname>SocketFactory</classname> to create a new
+ <classname>Socket</classname>.
+ </listitem>
+
+ <listitem>
+ The callback server invoker sends an internal message on the new
+ connection directing the server to replace the current control
+ connection with the new connection.
+ </listitem>
+
+ <listitem>
+ After the secondary <classname>ServerSocket</classname> creates a
+ new <classname>Socket</classname>, the <classname>Socket</classname>
+ is passed directly to the client invoker in a method that replaces
+ the old control connection with a new one.
+ </listitem>
+ </orderedlist>
+
+ <figure>
+ <title>Replacing a failed control connection.</title>
+ <graphic fileref="images/bisocket3.png"
+ width="765pt" depth="495"
+ contentwidth="765pt" contentdepth="445"
+ format="png" align="center"
+ />
+ </figure>
+
+ </section>
+ </section>
+
+ <section>
+ <title>SSL Bisocket invoker</title>
+
+ <para>
+ The SSL bisocket transport has the same relation to the bisocket
+ transport as the SSL socket transport has to the socket transport.
+ That is, it uses an <classname>SSLServerSocket</classname> and creates
+ <classname>SSLSocket</classname>s by default. See Section <xref
+ linkend="section-socket-factories"/> for more information.
+ </para>
+
+ <para>
+ SSL bisocket transport supports all the configuration attributes
+ supported by the bisocket transport.
+ </para>
+ </section>
+
</section>
<section>
@@ -2650,7 +3017,7 @@
compression.</para>
</section>
- <section>
+ <section id="section-callbacks" xreflabel="Callbacks">
<title>Callbacks</title>
<section>
@@ -4190,6 +4557,88 @@
</section>
<section>
+ <title>Socket creation listeners</title>
+
+ <para>
+ Every Remoting transport uses <classname>Socket</classname>s, but the
+ creation and management of the <classname>Socket</classname>s is
+ generally inaccessible from the application code. Remoting has a hook
+ that can provide access to <classname>Socket</classname>s, in the form
+ of a listener interface in the
+ <code>org.jboss.remoting.socketfactory</code> package:
+ </para>
+
+ <programlisting>
+ public interface SocketCreationListener
+ {
+ /**
+ * Called when a socket has been created.
+ *
+ * @param socket socket that has been created
+ * @param source SocketFactory or ServerSocket that created the socket
+ * @throws IOException
+ */
+ void socketCreated(Socket socket, Object source) throws IOException;
+ }
+ </programlisting>
+
+ <para>
+ Socket creation listeners can be registered to be informed every time a
+ socket is created by a <classname>SocketFactory</classname> or
+ <classname>ServerSocket</classname>. The mechanisms for registering
+ listeners are the usual ones, e.g., by putting them in configuration
+ maps passed to client and server invokers. (See Section <xref
+ linkend="section-configuration"/> for a general discussion of parameter
+ configuration in Remoting.) In any case they should be associated with
+ one of the following keys from
+ <classname>org.jboss.remoting.Remoting</classname>:
+ </para>
+
+ <programlisting>
+ /**
+ * Key for the configuration map passed to a Client or Connector to indicate
+ * a socket creation listener for sockets created by a SocketFactory.
+ */
+ public static final String SOCKET_CREATION_CLIENT_LISTENER = "socketCreationClientListener";
+
+ /**
+ * Key for the configuration map passed to a Client or Connector to indicate
+ * a socket creation listener for sockets created by a ServerSocket.
+ */
+ public static final String SOCKET_CREATION_SERVER_LISTENER = "socketCreationServerListener";
+ </programlisting>
+
+ <para>
+ The value associated with either of these keys can be an actual object,
+ or, to facilitate configuration by <classname>InvokerLocator</classname>
+ or xml, it can be the name of a class that implements
+ <classname>SocketCreationListener</classname> and has a default
+ constructor
+ </para>
+
+ <para>
+ Note that client and server invokers always use the respective keys
+ SOCKET_CREATION_CLIENT_LISTENER and SOCKET_CREATION_SERVER_LISTENER,
+ whether they are on the client side or server side. For example, a
+ callback client invoker would be configured by putting a listener with
+ the key SOCKET_CREATION_CLIENT_LISTENER in the configuration map passed
+ to the server side <classname>Connector</classname>, which will find its
+ way to the callback client invoker when a callback handler is registered.
+ </para>
+
+ <para>
+ The creation listener facility currently is supported by the following
+ transports: bisocket, sslbisocket, https, multiplex, sslmultiplex, rmi,
+ sslrmi, socket, and sslsocket. It is not supported by http because
+ <classname>HttpURLConnection</classname> does not expose its socket
+ factory (though <classname>HttpsURLConnection</classname> does). It is
+ not supported by the servlet transport because invocations with the
+ servlet transport go through a servlet container, which is outside the
+ scope of Remoting.
+ </para>
+ </section>
+
+ <section>
<title>SSL transports</title>
<para>There are now four transports that support SSL: https,
@@ -4914,7 +5363,208 @@
</section>
</section>
- <section id="section-configuration" xreflabel="Configuration by properties">
+ <section id="secction-timeouts" xreflabel="Timeouts">
+ <title>Timeouts</title>
+
+ <para>
+ The handling of timeouts in Remoting is surveyed in this section. On the
+ whole, timing out network connections is handled differently by each
+ transport, but there are some transport independent methods for timeout
+ configuration, extended by some transport specific methods.
+ </para>
+
+ <section>
+ <title>General timeout configuration</title>
+
+ <para>
+ As with all configuration parameters, there are several avenues for
+ specifying parameter values. See Section <xref
+ linkend="section-configuration"/> for a general discussion of parameter
+ configuration in Remoting. The transport independent key for setting
+ timeouts is "timeout", also available as
+ <code>org.jboss.remoting.ServerInvoker.TIMEOUT</code>. All server
+ invokers also have the getter/setter methods
+ </para>
+
+ <programlisting>
+ public int getTimeout();
+
+ public void setTimeout(int timeout);
+ </programlisting>
+
+ <para>
+ where the values are given in milliseconds. The default timeout value
+ is 60000 for server invokers.
+ </para>
+ </section>
+
+ <section>
+ <title>Per invocation timeouts</title>
+
+ <para>
+ Beginning with release 2.2.0, some Remoting transports offer a per
+ invocation transport facility, which allows a timeout value to be set
+ for a particular invocation, overriding the client invoker's previously
+ configured timeout value. The per invocation timeout is set by passing
+ the <classname>String</classname> representation of the timeout value in
+ the invocation's metadata map, using the key "timeout". For example,
+ </para>
+
+ <programlisting>
+ HashMap metadata = new HashMap();
+ metadata.put("timeout", "2000");
+ client.invoke("testInvocation", metadata);
+ </programlisting>
+
+ <para>
+ will allow approximately 2 seconds for this particular invocation, after
+ which the timeout value will be reset to its previously configured
+ value.
+ </para>
+
+ <para>
+ Each transport that supports per invocation timeouts handles them a
+ little differently. More details are given below.
+ </para>
+ </section>
+
+ <section>
+ <title>Transport specific timeout handling</title>
+
+ <section>
+ <title>Socket and bisocket transports</title>
+
+ <para>
+ These two transports are handled together because bisocket inherits
+ most of its timeout handling from socket. The discussion also applies
+ to their SSL versions, sslbisocket and sslsocket. On the server side,
+ the timeout value, whatever the source of its value, is used to set
+ the timeout value of all <classname>Socket</classname>s managed by the
+ server invoker's worker threads. On the client side, the configured
+ timeout value is used to limit the time required by
+ <methodname>Socket.connect()</methodname> when a new
+ <classname>Socket</classname> is created, as well as to set the
+ <classname>Socket</classname> timeout value for all connections in its
+ connection pool.
+ </para>
+
+ <para>
+ The socket and bisocket transports support per invocation timeouts.
+ The processing subject to the timeout period starts when the client
+ invoker begins to acquire a network connection and extends to the
+ point at which it begins reading the reponse to the invocation. Note
+ that the acquisition of the network connection might involve multiple
+ attempts to connect to the server.
+ </para>
+ </section>
+
+ <section>
+ <title>HTTP transport</title>
+
+ <para>
+ The http server invoker looks for a configured timeout value at
+ initialization time, which it uses to set the "connectionTimeout"
+ property on its Tomcat connector. (See Section <xref
+ linkend="section-http-invoker"/> for more information.) Note that
+ subsequent calls to <methodname>setTimeout()</methodname> will have no
+ effect.
+ </para>
+
+ <para>
+ The http client invoker treats timeouts configured for the connection
+ and per invocation timeouts the same, since it opens a new
+ <classname>HttpURLConnection</classname> with each invocation. Any
+ nonnegative per invocation timeout value will override a timeout value
+ configured at client invoker creation time.
+ </para>
+
+ <para>
+ If the application is using a jdk of generation 1.5 or later, then the
+ client invoker will use the
+ <classname>java.net.HttpURLConnection</classname> methods
+ <methodname>setConnectTimeout()</methodname> and
+ <methodname>setReadTimeout()</methodname> methods. Note that in this
+ case the timeout value will be allowed twice, once to create the
+ connection and once to read the invocation result.
+ </para>
+
+ <para>
+ If an earlier jdk is being used, the client invoker will simulate a
+ timeout by making the connection and executing the invocation in a
+ separate thread, which it waits on for the specified timeout. The
+ threads are drawn from a thread pool, which is configurable. A custom
+ thread pool may be set by calling the
+ <methodname>HTTPClientInvoker</methodname> method
+ </para>
+
+ <programlisting>
+ public void setTimeoutThreadPool(org.jboss.util.threadpool.ThreadPool pool);
+ </programlisting>
+
+ <para>
+ where the <methodname>ThreadPool</methodname> interface is available
+ from the anonomous JBoss svn repository at <ulink
+ url="http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java">
+ http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/</ulink>.
+ If a thread pool is not set, it will default to an instance of
+ <classname>org.jboss.util.threadpool.BasicThreadPool</classname>,
+ which may be configured with the following parameters,
+ defined as constants in
+ <classname>org.jboss.remoting.transport.http.HTTPClientInvoker</classname>:
+ </para>
+
+ <para>
+ <emphasis role="bold">MAX_NUM_TIMEOUT_THREADS</emphasis> (actual value
+ "maxNumTimeoutThreads"): the number of threads in the threadpool. The
+ default value is 10.
+ </para>
+
+ <para>
+ <emphasis role="bold">MAX_TIMEOUT_QUEUE_SIZE</emphasis> (actual value
+ "maxTimeoutQueueSize"): the size of the thread pool queue, which holds
+ execution requests when all of the threads are in use. The default
+ value is 1024.
+ </para>
+
+ </section>
+
+ <section>
+ <title>Quick client disconnect</title>
+
+ <para>
+ <classname>org.jboss.remoting.Client</classname> applies per
+ invocation timeouts in its <methodname>removeListener()</methodname>
+ and <methodname>disconnect()</methodname> methods to create a "quick
+ disconnect" facility. If, for example, an
+ <methodname>org.jboss.remoting.ConnectionValidator</methodname> (see
+ <xref linkend="chapter-connection-failure"/>) reports its suspicion
+ that a connection is failing, the application might want to restrict,
+ or even eliminate, the time spent trying to access the network
+ while unregistering callback handlers and disconnecting.
+ The quick disconnect facility is invoked by calling the
+ <classname>Client</classname> method
+ </para>
+
+ <programlisting>
+ public void setDisconnectTimeout(int disconnectTimeout);
+ </programlisting>
+
+ <para>
+ to set the disconnect timeout value to a nonnegative value.
+ If the disconnect timeout value is set, it will be applied as the per
+ invocation timeout value for all network activity in the methods
+ <methodname>removeListener()</methodname> and
+ <methodname>disconnect()</methodname>. As a special case, if the
+ disconnect timeout value is set to 0, <classname>Client</classname>
+ will simply skip any network i/o in these two methods.
+ </para>
+
+ </section>
+ </section>
+
+ </section>
+
+ <section id="section-configuration-by-properties" xreflabel="Configuration by properties">
<title>Configuration by properties</title>
<para>This section covers configuration properties by constant values and
More information about the jboss-cvs-commits
mailing list