NIO - PooledInvoker Question

[sebastiendeg]

Hi All,

I'm trying to find out exactly what I can do with JBoss AS and JBoss Remoting in term of Remote Invocation performance and scalability.

We are currently using a custom Remote Invocation Mechanism which uses apache Mina for Scalability.

We are on the process of migrating to JBoss (4.2.2) with EJB 3.0.
We would use EJB 3.0 Remote Session Bean (which use RMI).


The question :

Does JBoss Remoting use NIO or something similar or even better (for Scalability) ?

If so, can I use that for my remote EJB call by customizing the invoker inside JBoss ?


Thanks.

[dmlloyd]

JBoss Remoting 2.x uses blocking I/O, but Remoting 3.x (still in development) uses NIO. My hope is that Remoting 3 will be finished in time for the release of JBossAS 5.1, which is a bit down the road yet.

[sebastiendeg]

given that fact that JBoss has an option to reuse Thread for RMI request,

What would you say about moving from Custom RPC with Mina to JBoss 4.2.2 which uses JBoss remoting 2.x ?

Regards,
Sebastien

[ron_sigal]

Hi Sebastien,

Remoting is the greatest thing since sliced worms. No question about it.

Seriously, though, when you say "RMI", are you referring to Java RMI or generic "remote method invocation"? Actually, Remoting offers both, in the sense that there is an "RMI" transport that uses Java RMI and a "socket" transport that implements the usual "old i/o" structure of an acceptor thread and multiple worker threads. The latter is the default transport for EJB3s. You can certainly use hundreds of worker threads. Your mileage may vary as to when the performance starts leveling off. You might want to try some simple experiments to see how invocations with Remoting compare to your MINA based system. If you get some interesting results, please let us know.

Of course, one advantage to using Remoting is that when something goes wrong, you have someone else to blame. :-)

[sebastiendeg]

Hi Ron,

Tks for you response.

I thought JBoss EJB 3.0 was using RMI, that's why I said RMI :-)

Any reason to use Socket based instead of RMI ? What's the recommendation ?

After fews test, JBoss remoting is promising, specially also beceause it does not keep the connection open between client and server.

We also really like the Multiplex system that reduce the number of conection needed on server side.

I Will let you know the outcomes of our further tests.

Cheers,
Sebastien

[ron_sigal]

Hi Sebastien,

The "socket" transport is somewhat faster than the "rmi" transport. When paired with JBossSerialization, it's about twice as fast, at least in some tests.

The client side of the socket transport maintains a pool of connections, which it closes when the client disconnects.

I'm sorry to say that the multiplex transport is no longer supported. The next generation of Remoting, Remoting 3, will support shared connections.

-Ron

[sebastiendeg]

Hi Ron,

I beleive if you remove the multiplex for shared connection, there is a good reason for that, isn't it ?

Does EJB 3.0 uses JBoss Remoting as any application would ? I mean, does it make any tweak for EJB stuff ?


Cheers,
Sebastien

[ron_sigal]

Hi Sebastien,

I beleive if you remove the multiplex for shared connection, there is a good reason for that, isn't it ?

1. The multiplex transport just didn't have many users, so it didn't seem worth the effort to continue to support it.

2. Remoting 3 will offer a similar facility.

Does EJB 3.0 uses JBoss Remoting as any application would ? I mean, does it make any tweak for EJB stuff ?

Yes and no. The EJB3 configuration of a Remoting server is quite straightforward:

 <mbean code="org.jboss.remoting.transport.Connector"
 name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
 <depends>jboss.aop:service=AspectDeployer</depends>
 <attribute name="InvokerLocator">socket://${jboss.bind.address}:3873</attribute>
 <attribute name="Configuration">
 <handlers>
 <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
 </handlers>
 </attribute>
 </mbean>

On the other hand, there are some sophisticated things happening on top of Remoting. There are aop (aspect orient programming) interceptors embedded in the client side proxy that talks to the server, and there is a dispatcher in the server side ServerInvocationHandler that manages the EJB3s.