Skip to content

JGroups; Hopes and Regrets

October 16, 2010

Undoubtedly JGroups is a great framework. For me, it’s a hidden gem that always helps me build distributed systems. Although it’s usually considered as a building block not a high-level framework, but I’ve always preferred to use it directly rather than nice wrappers such as Coherence and JBossCache/Infinispan or GridGain.

Now after running my third project project on top of it, I’ve got better feeling of it’s pros and cons.

You know, the great thing behind JGroups is that it hits its goal quite well. The goal is to have a Java Group Communication framework and JGroups does this very well.

We are setting up a large cluster for Image processing. The nodes count in the initial demo is only 128 but it may soon increase to 2K in later setups. Configuring JGroups to run in such an environment not an easy task at all. One need to have deep understanding of UDP/IP and Java internals to get the results. This is maybe one minor deficiency of JGroups but it’s bearable due.

The second issue is all about that big ‘J’ :) IMHO JGroups is far beyond a framework just to be limited to Java. JGroups highly depends on Java and it’s serialization and the commiters do not seem to be much interested to standards communication stack and and permit pluggable serialization mechanism. Something somehow similar to Inifispan HotRod.

For example, we have noticed that our native image processing code running better in SMP machines with Python/SWIG than Java/JNA/JNI but there is almost no way to keep servers in Java and switch clients to Python.

This sometimes makes me think of switching to ZooKeeper/Google Protocol Buffer rather than staying with JGroups. I don’t know till when I can resist it :) Recently I saw a LinkedIn project called Norbet that is almost exactly what I had in mind, but will ZK give me a fast distributed hash map like JGroups? Norbet code base is young but definitely deserves a try.

Advertisements
4 Comments
  1. You seem to suggest that Infinispan Hot Rod’s serialization is only limited to Java and not pluggable. On the contrary, Hot Rod uses byte[] key/value pairs, which means that you can store anything on it.

    Moreover, Java Hot Rod client can, from 5.0 onwards, be plugged with an Apache Avro based marshaller, see http://community.jboss.org/docs/DOC-15774

    What this means is that once there’re clients in other languages, we’ll be able to fully interact between diff environments.

    Besides, since we take a byte[] as key/value pairs, you can take your favourite marshalling framework, i.e. protobufs, generate the payload for your pojo and stick it in.

    • abbaspour permalink

      Dear Galder,
      Oops, my poor English seems to cause it. I tried to say that Hot Rod is not limited to Java and is pluggable and hoped for JGroups to support a similar protocol. As you said Hot Rod is language natural and can be used to easily plug other langs/marshalings to Inifinispan.

      Thanks for comment.

  2. I’m actually working on STOMP support for JGroups, see [1], so that clients can connect to JGroups and send / receive messages. I used stompyy (Python) yesterday to connect and it worked fine.

    The STOMP protocol is only ca 30% done, I’m going to post to the JGroups mailing list once it is in a usable state.

    [1] http://javagroups.cvs.sourceforge.net/viewvc/javagroups/JGroups/src/org/jgroups/protocols/STOMP.java?revision=1.6&view=markup

  3. abbaspour permalink

    It’s cool to hear that Bela. I’ll check out and try 2.11 asap.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: