Monday, January 05, 2009

JGroups 2.7 released

Finally, after almost a year of development, I released 2.7.0.GA this morning. It can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=6081&package_id=94868&release_id=651542.

Although 2.7 has 211 JIRA issues (bugfixes, tasks or features), most of the bugs have been back ported to the 2.6 branch. Why ? Because 2.6.7 is the version that ships with JBoss 5, and we made sure JGroups works optimally with it.

So what's new ?

There are almost no new features ! (Can you tell I'm not a marketing person ? :-))

Most work (besides bug fixes) went into refactoring, e.g. we converted our test suite from JUnit to TestNG, allowing for parallel test execution and thus reduced our testing time from 2.5 hours to 15 minutes !

Another change was that all properties are now set using JSR 175 annotations, so we could remove a lot of boilerplate code from protocol implementations. In my opinion, the more code I can remove (without impacting functionality), the better !

Using annotations for properties also allows us to automatically generate documentation for the properties of all protocols.

I also marked unsupported or experimental classes/methods with @Unsupported or @Experimental annotations.

We were able to increase performance a bit, compared to 2.6, but 2.6 is already quite fast, so unless you need those additional 5-10%, go for 2.6.7.

In a nutshell, 2.7 serves as the groundwork for 2.8, which will have many new features.

14 comments:

  1. Nice, is it enough stable to be used in production?
    I would love to see it on a maven repository.

    Thanks

    Antonio

    ReplyDelete
  2. Yes, 2.7 is as stable as 2.6.7, which is shipped with JBoss 5.

    I'll create a task to place it into a Maven repo. Which repo were you thinking of ?

    ReplyDelete
  3. Hey Bela,

    Good to see you blogging. I am long time user of JGroups (since JavaGroups circa 2001). Hope to see more of your thoughts.

    Kumar.

    ReplyDelete
  4. Hey Kumar,

    yes, you were one of the first people to be willing to play guinea pig and try out (then called) JavaGroups. Good to see you're still using it ! :-)
    Yes, I hope to blog more. The next post should come today, stay tuned !
    Bela

    ReplyDelete
  5. Hi Bela,

    I was wondering if different versions of JGroups are compatible. If so, is there a compatibility matrix /guidelines somewhere?

    Thanks,
    Chandra.

    ReplyDelete
  6. Yes, http://www.jboss.org/jbosscache/compatibility/index.html shows a compatibility matrix between JGroups, JBossCache and JBoss AS.

    The compatibility rule JGroups follows is:
    - A version is X,Y,Z, where X is the major, Y the minor and Z the patch version
    - Major versions can break API and binary (= wire format) compatibility
    - Minor versions cannot break API compatibility, but may or may not break binary compatibility
    - Patch versions must NOT break either API or binary compatibility

    ReplyDelete
  7. Regarding Antonio's question: actually we already *do* push JGroups releases into our Maven repo: at http://repository.jboss.org/maven2/jgroups/jgroups/2.7.0.GA/ you can see the 2.7.0.GA release.

    ReplyDelete
  8. What happened to JMS support? Seems to be gone now.

    ReplyDelete
  9. Yes, I pulled it. Nobody ever used it, it was unsupported and I never liked the idea of using JMS in the first place !

    ReplyDelete
  10. Bela,

    Good to see the project is still alive and kicking. I thought you'd like to know that I've used JGroups along with MINA, Spring, Hibernate and Derby to implement a self-configuring, self-maintaining application fabric.

    JGroups provides the replication of the data describing the underlying infrastructure and applications and Hibernate and Derby provide a simple, data store that is created on the fly at each node or machine using the Spring/Hibernate configuration. MINA provides the front-end for command processing.

    JGroups allows for data to be replicated across all nodes seamlessly. It was easy to use and solid. Congrats on a job well done.

    ReplyDelete
  11. Bela,

    Good to see the project is still alive and kicking. I thought you'd like to know that I've used JGroups along with MINA, Spring, Hibernate and Derby to implement a self-configuring, self-maintaining application fabric.

    JGroups provides the replication of the data describing the underlying infrastructure and applications and Hibernate and Derby provide a simple, data store that is created on the fly at each node or machine using the Spring/Hibernate configuration. MINA provides the front-end for command processing.

    JGroups allows for data to be replicated across all nodes seamlessly. It was easy to use and solid. Congrats on a job well done.

    ReplyDelete
  12. Thanks William !

    Always interested hearing about success stories (http://www.jgroups.org/success.html) !

    ReplyDelete
  13. Anonymous3:22 AM

    Hi Bela, I'd like to make a comment about your above statement on compatibility. Although 2.x is in theory API compatible across all minor versions, the fact that the default implementation of Address was changed in JGroups 2.8 introduced an effective incompatibility for any code which makes assumptions about the implementation.

    We are using JBoss 4.0.5 and have just upgraded to JGroups 2.6.10.GA. We couldn't upgrade to a later JGroups because of the implementation change. JBoss 4.0.5 assumes that the default implementation is IpAddress, and if we try to use JGroups 2.8+ we thus get class cast exceptions all over the place. Anyhow 2.6.10.GA is working pretty well for us.

    So -- unless I've misunderstood something here -- it seems an interesting example of how the statement that JGroups 2.x is API compatible across all minor versions can be strictly true, yet not really true. :)

    ReplyDelete
  14. Yes, you caught me there... JBossAS made a mistake and used IpAddress directly, whereas it should have used Address, as an opaque type.
    Going from 2.7 to 2.8, I had the choice of staying backward-compatible, or introduce logical addresses. Because logical addresses were very important IMO (prevention of reincarnation issues), I took the liberty of making this (incompatible) change.
    Note that 2.6.10 is not the latest release of the 2.6 branch, the latest is 2.6.15 (or even .16, IIRC).
    Cheers,

    ReplyDelete