It has taken us almost a year since the last major release (2.7 was released in January), but to our defense 2.8.0.GA contains a lot of new features and I think they are worth the wait. We also released a number of 2.6.x versions in 2009, which are used in the JBoss Enterprise Application Platform (EAP).
Before I get into a summary of some of the new features (a detailed list can be found at [1]), I'd like to thank all the developers, users and contributors of JGroups. Without this healthy community, producing code, bug reports, patches, documentation and user stories, JGroups wouldn't be anywhere close to where it is today !
So a big thanks to everyone involved, Happy Holidays and a great start into 2010 !
Here's a short list of features that made it into 2.8.0.GA (here are the release notes):
- Logical addresses: decouples physical addresses (which can change) from logical ones. Eliminates reincarnation issues. This alone is worth 2.8, as it eliminates a big source of problems !
- Logical names: allow for meaningful channel names, logical names stay with a channel for its lifetime, even after reconnecting it
- Improved merging / no more shunning: shunning was replaced by merging. Now we have a much simpler model: JOIN - LEAVE - MERGE. The merging algorithm was improved to take 'weird' (e.g. asymmetric) merges into account
- Better IPv6 support
- Better support for defaults for addresses: based on the type of the stack (IPv4, IPv6), we perform sanity checks and set default addresses of the correct type
- FILE_PING / S3_PING: new discovery protocols, file-based and Amazon S3 based. The latter protocol can be used as a replacement for GossipRouter on EC2
- Speaking of which: major overhaul of GossipRouter
- Ability to have multiple protocols of the same class in the same stack
- Ability to override message bundling on a per-message basis
- Much improved and faster UNICAST
- XSD schema for protocol configurations
- STREAMING_STATE_TRANSFER now doesn't need to use TCP, but can also use the configured transport, e.g. UDP
- RpcDispatcher: additional methods returning a Future rather than blocking
- Probe.sh: ability to invoke methods cluster-wide. E.g. run message stability on all nodes: probe.sh invoke=STABLE.runMessageGarbageCollection
- Logging
- Removal of commons-logging.jar: JGroups now has ZERO dependencies !
- Configure logging level at runtime, e.g. through JMX (jconsole) or probe.sh, or programmatically. Use case: set logging for NAKACK from "warn" to "trace" for a unit test, then reset it back to "warn"
- Ability to set custom log provider. This allows for support of new logging frameworks (JGroups ships with support for log4j and JDK logging)
Bela, Vladimir and Richard
[1] http://javagroups.cvs.sourceforge.net/viewvc/javagroups/JGroups/doc/ReleaseNotes-2.8.txt?revision=1.10&view=markup&pathrev=Branch_JGroups_2_8
[2] http://community.jboss.org/wiki/Support
This comment has been removed by a blog administrator.
ReplyDeleteCongrats on some great work. I've used JGroups time and time again in many projects with great success.
ReplyDeleteSo...what's planned for 3.0? :)
Thanks !
ReplyDeleteWell, before 3.0, we've got 2.9... :-)
Some of the things we want to do in 2.9 [1] are:
- Ergonomics (e.g. rate adjusted flow control)
- Large scale clusters
- Better cloud support (e.g. scalable TCP)
- Scopes (different msgs from the same sender can get processed concurrently at the receiver)
- Perf improvements (mainly for 10GB and larger clusters)
In 3.0, we will break code by making all API-related changes we've been accumulating since 2.5, plus:
- Copyless stack: using the NIO-2 subsystem in Java 7, we'll be able to *not* copy a message going down the stack, or up the stack
- Further work on ergonomics: the goal here is that a user simply lists the protocols to be used in a config, but doesn't need to define any properties, as JGroups sets the right props and possibly changes them at runtime. This is similar to the JVM where you only need to set -Xmx and -Xms in more recent releases
Cheers,
Bela
[1] https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10053&fixfor=12313378
Bela, how does it compare with 2.7 in terms of performance?
ReplyDeleteHi Galder,
ReplyDeleteit's slightly better than 2.6.13 (I don't really support 2.7), but even 2.6.13 was pretty fast. On a 4-8 node cluster, I can saturate a 1 Gbps network with perf.Test, so we can't get much better !
Example numbers: on a 4 node cluster with a 1 Gbps switch, I get ca 150 MBytes / sec / node of throughput, sending 1 million 2500 byte messages / node. The reason this is higher than the 125 MByte/sec limit of 1 Gbps networks is that every sender loops back the local multicasts, the switch doesn't return multicasts from P back to P.
Hi Bela,
ReplyDeleteCongrats on the new release!
This is probaly not the place to ask this, but it is a recent thread.
We have written a JCA compliant adapter (ie for JEE) which externalizes the jgroups configuration neatly and pools the jgroups channels.
We would like to donate the adapter to jgroups, if you would like it. how can we go about doing this?
Hi Daniel,
ReplyDeletethanks !
The best place to discuss is the jg-dev mailing list . I know close to nothing about JCA, but if this requires pulling in additional JARs, then this can't be in the kernel JAR. maybe contrib, tdb.
Brian Stansberry might be interested in this, too, but he's also subscribed to jg-dev, so he'd be able to take a look and comment.
Cheers,
Bela
Thanks, will do.
ReplyDeletecheers