One of the goals while creating JBossRemoting is to make it so that others can plug in their custom implementations without have to re-write a lot of the current code.  This page will cover specific places where these custom implementations can be plugged in.  If you have such a need and don't see a way to do it, let me know and I will either point you in the right direction or add it (tom at jboss). 

Custom streams for socket invoker

The socket invokers (client and server) now use an implementation of org.jboss.remoting.transport.socket.SocketWrapper to create the desired input and output streams around the socket's streams to be used by the marshaller/unmarshaller.  By default, the client and server invoker use the org.jboss.remoting.transport.socket.ClientSocketWrapper and org.jboss.remoting.transport.socket.ServerSocketWrapper repectivly. 

To replace these default implementations, create your own implementation of the SocketWrapper class and extend where needed.  In particular, you will find the following methods:

   public abstract OutputStream getOutputStream();
   public abstract InputStream getInputStream();

which will allow for any custom stream to be returned, as long as it extends the OutputStream/InputStream classes.

To declare that the socket invoker should use the custom SocketWrapper implementation, specify the following properties within the invoker configuration (see http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Transports_Configuration for how to configure invoker properties).

clientSocketClass - specifies the fully qualified class name for the custom SocketWrapper implementation to use on the client.  Note, will need to make sure this is marked as a client parameter (using the 'isParam' attribute).

serverSocketClass - specifies the fully qualifies class name for the custom SocketWrapper implementation ot use on the server. 

Making this change will not affect the marshaller/unmarshaller that is used, which may also be a requirement.  For more information on how to specify a custom marshaller/unmarshaller, please refer to http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Marshaller_Configuration.

Custom thread pools

There are several places within JBossRemoting that thread pools are used.  Each of these will use the org.jboss.util.threadpool.BasicThreadPool implementation for the thread pool by default.  However, in each case, these can be replaced by any implementation of org.jboss.util.threadpool.ThreadPool interface.  Both the BasicThreadPool class and the ThreadPool interface can be found within the jboss-common.jar. 

Oneway thread pool

Both the server invoker and the client contain thread pools for making one way (asynchronous) invocations.  For the server invoker the thread pool can be customized by setting the following properties:

maxNumThreadsOneway - specifies the maximum number of threads to be used within the thread pool for accepting one way invocations on the server side.  This property will only be used in the case that the default thread pool is used.  If a custom thread pool is set, this property will have no meaning.  This property can also be retreived or set programmatically via the MaxNumberOfOnewayThreads property.

onewayThreadPool - specifies either the fully qualified class name for a class that implements the org.jboss.util.threadpool.ThreadPool interface or the JMX ObjectName for a MBean that implements the org.jboss.util.threadpool.ThreadPool interface.  This will replace the default BasicThreadPool used by the server invoker.  Note that this value will NOT be retrieved until the first one way (server side) invocation is made.  So if the configuration is invalid, will not be detected until this first call is made.  The thread pool can also be accessed or set via the OnewayThreadPool property programmatically.

Important to note that the default thread pool used for the one way invocations on the server side will block the calling thread if all the threads in the pool are in use until one is released.

Currently, the client side oneway thread pool properties (OnewayThreadPool and MaxNumberOfThreads) can only be retrieved or set programmatically.

HTTP thread pool

The HTTPServerInvoker, which is basically a simple web server, also uses a thread pool for processing incoming requests.  This thread pool can be customized by setting the following properties:

maxNumThreadsHTTP - specifies the maximum number of threads to be used within the thread pool used receive incoming requests.  This property will only be used in the case that the default thread pool is used.  If a custom thread pool is set, this property has no meaning.  This property can also be retreived or set programatically via the MaxNumberOfHTTPThreads property.

HTTPThreadPool - specifies either the fully qualified class name for a class that implements the org.jboss.util.threadpool.ThreadPool interface or the JMX ObjectName for a MBean that implements the org.jboss.util.threadpool.ThreadPool interface.  This will replace the default BasicThreadPool used by the HTTPServerInvoker.

The org.jboss.test.remoting.configuration.threadpool.HTTPThreadPoolConfigurationTestCase test cases demonstrates how to set a custom ThreadPool implementation via configuration.