JBoss Messaging is JBoss' implementation of a JMS 1.1 messaging provider. JBoss Messaging evolved from SpyderMQ, and the current release has been available in a production version since this March.

The JBoss Messaging team posted the next version's alpha last week. The main new feature in 1.1 is clustering support, leading messaging team member Tim Fox to claim in a recent blog post, State of the art clustering with JBoss Messaging, that:

Actually I know of only one messaging system that has a comparable feature set, and it's proprietary. As far as I know (and I am happy to be corrected) there is nothing in the open source space that touches us when it comes to clustering...

We leverage the tried and test[ed] power of JGroups for all our network group management and transmission requirements.

Fox notes intelligent message routing as one of the most interesting features of 1.2 Alpha:

You've routed messages to partial queues, but consumers get closed or slow down on a particular node causing messages to build up or get stranded. On another node the consumers are processing messages faster than they are arriving, wasting CPU cycles as they wait for the next message to arrive. JBoss Messaging clustering allows nodes with fast consumers to pull messages from slower nodes in order to balance the load... The policy as to how and when this happens is fully pluggable.

Another advanced feature is in-memory persistent message replication:

The idea here is as follows: Most messaging systems have the concept of "once and only once delivery". This is normally achieved by persisting messages in "permanent" storage (e.g. a database or file store). The problem is that permanent storage usually means writing to disk and disk synching, which is slow.

The problem gets further compounded when the storage is shared - e.g. a shared Oracle database, since not only do you have to disc synch, but you also have a point of contention, a bottleneck in the system which hampers the ability of the system to scale.

Ok, solutions such as Oracle RAC go some way to address these problems but scaling databases horizontally is not an easy (or cheap) problem to solve... But there's another way we can increase the "durability" of a message without storing it to disk at all, and that's by replicating it in memory between different nodes. If the cluster is well constructed with good hardware, UPS etc, then we can reach sufficiently levels of durability for many applications.

Additional clustering features in the 1.2 Alpha include:

Seamless client failover.

No single point of failure (SPOF) or single point of bottleneck (SPOB).

Fully distributed topics.

Fully distributed queues.
You deploy a JMS queue on the cluster, [and] create consumers on any node and send messages on any node. Each node maintains it's own "partial queue", so there is no singleton "master queue" that all the nodes have to access.

Shared durable subscriptions.
If you create a durable subscription, you can consume from it from different nodes... Like queues, we create partial subscriptions distributed across the nodes.

Pluggable routing policy.
If you send a message to a queue while attached to a particular node, should the message be routed to the partial queue on that node or on another node? This is determined by the routing policy. By default it will always choose the local partial queue. But if the local queue has no consumers then it will choose another queue.

JBoss' support for clustering in its open-source JMS implementation is more evidence that high-availability features are moving from expensive, commercial products to open-source projects. But opting for a high-availability solution is as much a question of trust in the product or implementation as it is a question of a product's technical merits. To what extent do you trust open-source products to replace proprietary ones for mission-critical, high-availability features, such as clustering?