JBoss Remoting + JBoss Serialization kills JavaRMI and Spring Remoting

We have found recently this powerful libray provided by JBoss.

The performance we have gain in terms of speed is that JBossRemoting + JBossSerlization is 8.72 times faster than JavaRMI + JavaSerialization (JDK 6 update 11)

In our real scenario, basically we are sending a list of around 100000 user defined objects from clients to servers. This data It is around 15MB.each message call

The clustered architecture we have deployed is not relevant to mention; but what I want to point; it is how easy has been to move from Java RMI to JBoss Remoting.  Just one line of code and you have your server and client applications running.

//server side code
//where this is the target object
TransporterServer.createTransporterServer("socket://"+ yourhostname+": port/?serializationtype=jboss", this, serverName);

//client side code
//where remoteServerClass.class is just the remote server interface like RMI
remoteServer = (T) TransporterClient.createTransporterClient("socket://"+remoteHostname+":remotePort/?serializationtype=jboss" , remoteServerClass.class);

Once you get the remote reference to the remote object, you can invoke methods on the object running in the remote Java virtual machine. The same way you do it for your RMI solution.

The purpose of JBoss Remoting is to provide a single API for most network based invocations and related service that uses pluggable transports and data marshallers. The JBoss Remoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the addition of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes, to fit these different needs
JBoss Remoting

JBoss provides nice features such Pluggable transports, Callbacks and many other, so you do not have to re-invent the wheel.

Although we are using version 2.5, and we are waiting for the forthcoming 3.0, there is complete performance test report where you can compare JBoss implementation against Java and Spring Remoting.

JBoss Performance Benchmark

8 Comments on “JBoss Remoting + JBoss Serialization kills JavaRMI and Spring Remoting”

  1. #1 John Mazz
    on Feb 19th, 2009 at 6:07 pm

    I agree – JBoss Remoting is a very powerful and flexible API. It is the backbone to the communications between server and agent in the Jopr project (http://www.jboss.org/jopr/). It has never been a bottleneck for us – as fast as we can pump messages through it, it can handle it.

  2. #2 Rich Sharples’ Blog » Blog Archive » Tab Sweep : JBoss
    on Feb 20th, 2009 at 4:06 pm

    [...] a nice blog post on benchmarking of JBoss Remoting and JBoss Serialization which claims that it’s almost 9 [...]

  3. #3 Clebert Suconic
    on Feb 20th, 2009 at 11:33 pm

    Nice post!

  4. #4 Mika
    on Feb 23rd, 2009 at 9:17 pm

    It would be nice if spring remoting supported jboss remoting. Another option for burlap/hessian, rmi and httpinvoker for use with spring beans. It would seem quite possible.

  5. #5 Rich
    on Apr 7th, 2009 at 9:06 pm

    I’m testing JBoss Serialization right now and I’m not seeing any major performance benefit over java Object*Stream classes for bulk transfers.

    Could you clarify if you are sending 1 object per call or if you are sending all 100000 objects in a list or array all at once?

    If you are sending one object at a time the invocation performance increase given by the JBoss Remoting framework is where you are getting your speed increase since RMI incurs a lot of overhead per method call.

    I did however find that Hessian2 protocol was highly compressed in respect to java Object*Stream serialization and performed much, much better. The caveat with Hessian being that you have a much reduced set of options for doing the actual remoting part of the problem (used servlet api + jetty).

  6. #6 Alfonso Olias
    on Apr 8th, 2009 at 9:15 am

    Hi Rich,

    We are sending all the user defined objects (100000) in an ArrayList in one call. We have done other tests sending primitive types in arrays

    double [] dataBlock1; // new double[1024];
    double [] dataBlock2; // new double[2*1024];
    // 4,8,16,32,500,1000,2000,3000,10000

    You are right with the fact that JavaRMI and JBossRemoting+JBossSerialization have the same performance but only when it is just one thread that sends the data.

    In our case, we have 8 running threads in the same JVM sending data concurrently to the same server. We also tried different scenarios with Java RMI such:

    • * All the threads sharing the same Remote Reference
    • * All of them getting a new Remote Reference

    But there was no difference in the performance with the Sun JVM.

    The actual implementation of our software, all the threads (8 threads running on a quadcore, JVM 6 update 13) are sharing the same JBoss Remote Reference. And the performance is much more higher than RMI as I posted. So the bottleneck has to be related with some wrong implemented synchronization over the data streaming.


  7. #7 Ron Sigal
    on Apr 16th, 2009 at 7:28 am

    Hi Alfonso,

    As a member of the Remoting group at JBoss, I want to thank you for testing and commenting on our project. Although our download numbers are typically in the 3 to 4 decimal digit range (which, if I’m not mistaken, puts us somewhat behind Firefox), Remoting is the default transport for versions 4.2 and 5.0 of the JBoss Application Server , so we’re definitely getting a lot of use, if not a lot of attention.

    As good open source citizens, we try to be responsive to our users, and we invite folks to contribute to the Remoting users forum at http://www.jboss.org/index.html?module=bb&op=viewforum&f=222 .

    Finally, a tip of the hat to Tom Elrod and Clebert Suconic, the respective founders of JBoss Remoting and Serialization.

    -Ron Sigal

  8. #8 deepak
    on Jan 12th, 2013 at 8:46 pm

    Is JBoss Remoting project currently active, and supported by JBOSS group? I was looking for a remoting solution, but wasn’t sure whether Jboss remoting is still supported. Thanks.

Leave a Comment