Invokers (JRMP, Pooled, and Unified)

The JBoss Detached Invokers are already covered within section 2.7 of the JBoss Application Server Guides (see http://www.jboss.com/products/jbossas/docs for links to the different guide versions).  This page is meant as a supplement to that document and to go into more detail about the differences between the JRMPInvoker and the PooledInvoker and why to choose one over the other.  This page will also cover the new UnifiedInvoker, which will be used in future releases.

But just as a reminder (for those who will read this first), as stated in the JBoss Application Server Guide, the detached invoker is a:

... concept that allows MBean services to expose functional interfaces via arbitrary protocols for remote access by clients. This notion first showed up in 3.0 for the EJB container and it has been further generalized to any MBean service in 3.2. The notion of a detached invoker is that remoting and the protocol by which a service is accessed is a functional aspect or service from independent of the component.

-

JRMPInvoker

The org.jboss.invocation.jrmp.server.JRMPInvoker class is an MBean service that provides the RMI/JRMP implementation of the Invoker interface. The JRMPInvoker exports itself as an RMI server so that when it is used as the Invoker in a remote client, the JRMPInvoker stub is sent to the client instead and invocations use the RMI/JRMP protocol.

To date, the JRMPInvoker is the default invoker used within JBoss for ejb invocations (meaning 4.0.3SP1 and below).

Pros

• RMI/JRMP is a standard.  This means will be easier to understand its capabilities and features.  Will also make it easier to understand if looking at the source (since many references available on RMI/JRMP). 

• Dyanmaic class loading.  RMI/JRMP has the ability to dynamically download classes over the wire that are not present on the client.  For more information on this, see http://wiki.jboss.org/wiki/Wiki.jsp?page=RMIClassLoadingService.

Cons

• By default, will create a new client socket for each request it makes on the client to the server.  The overhead of creating this new client socket for each request when there are many back to back calls can be expensive performance wise.

• By default, very little control over tuning the implementation (i.e. can not throttle througput via any configuration attributes).

• Up until JBoss 3.2.7+ and 4.0.2+, the JRMPInvokerHA (this is the clustered one that provides failover), did not support failure retries on the client.  This means that if a client has looked up an ejb from a server and that ejb is redeployed, the client reference is no longer valid, and would have to manually lookup the ejb again.

The first two negatives can be overcome by implementing custom socket factories which provide implementations that provide the custom functionality desired, but requires a lot of work and is no way to generically configure them (other than just setting what the factories to use should be).

PooledInvoker

The org.jboss.invocation.pooled.server.PooledInvoker is an MBean service that provides RMI over a custom socket transport implementation of the Invoker interface. The PooledInvoker exports itself as an RMI server so that when it is used as the Invoker in a remote client, the PooledInvoker stub is sent to the client instead and invocations use the a custom socket protocol.

Note, when state RMI in description above, this is for remote method invocation and does not mean that the PooledInvoker implements the RMI/JRMP specification.  It is a custom implementations that uses sockets directly.

Pros

• Will pool the client socket connections to a server using a keep alive ping while idle for a short period of time.  If the client makes another call to the server within this short period of time, the same open socket conenction will be used instead of creating a new client socket.  Note: In a very simple test of continually making ejb calls using JRMPInvoker and then PooledInvoker, a 10% performance increase was seen using the PooledInvoker.  This is by no means an official benchmark, but gives some insight into the difference.

• Grandular configuration for throttling through put.  The configuration attributes such as, NumAcceptThreads, MaxPoolSize, ClientMaxPoolSize, Backlog, and EnableTcpNoDelay, allow for much better control of how the client and server will behave under heavy load. 

• Client connection routing through network devices (routers, firewalls, NAT, etc.).  Can specify the address and port that the client should connect to in the case that the external address and port to the server are different than the internal network address and port. 

• Tollerant of server side redeploys.  If the ejb on the server is redeployed, the PooledInvoker client can still make connection back to the ejb after it has been redeployed.

Cons

• Does not have the Pros of JRMPInvoker.

• Can not plug in custom socket factories.

For information on how to configure PooledInvoker as the default detached invoker within JBoss, refer to http://wiki.jboss.org/wiki/Wiki.jsp?page=PooledInvokerConfig.

Unified Invoker

The precursor to the remoting framework was the detached invoker framework described in chapter 2 of the online admin and devel guide. Its a jmx centric framework that has an mbean that handles the transport, proxy creation, and routing of messages passed over the transport to an mbean target.

There is a new invoker called Unified Invoker which is based on JBossRemoting.  It's interface is that of the other detached invokers, but instead of having a different implementation for each transport, there is one UnifiedInvoker which changes it's transport based on configuration (via JBossRemoting).

UnifiedInvoker & UnifiedInvokerHA documentation can be found at http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html

UnifiedInvoker configuration (which is old, so should use previous link).

The UnifiedInvoker(HA) is available in HEAD currently (and is configured as the default invoker) and the 4.0 branch (at HEAD) and is targeted for 4.0.4 (although will not be configured as the default invoker).