7 Replies Latest reply on Jun 5, 2008 12:20 PM by Ron Sigal

    NIO - PooledInvoker Question

    Sebastien Degardin Newbie

      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.

        • 1. Re: NIO - PooledInvoker Question
          David Lloyd Master

          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.

          • 2. Re: NIO - PooledInvoker Question
            Sebastien Degardin Newbie

            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

            • 3. Re: NIO - PooledInvoker Question
              Ron Sigal Master

              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. :-)

              • 4. Re: NIO - PooledInvoker Question
                Sebastien Degardin Newbie

                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

                • 5. Re: NIO - PooledInvoker Question
                  Ron Sigal Master

                  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

                  • 6. Re: NIO - PooledInvoker Question
                    Sebastien Degardin Newbie

                    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

                    • 7. Re: NIO - PooledInvoker Question
                      Ron Sigal Master

                      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.