Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News JBoss Messaging Matures with Clustering & Transparent Failover Support

JBoss Messaging Matures with Clustering & Transparent Failover Support

A couple of weeks ago JBoss (now part of Red Hat) released the latest version of its JMS product, JBoss Messaging 1.2. The product has been around for a while as a replacement for the aging JBossMQ, but this release is an important milestone for Red Hat as it finally adds necessary clustering and transparent failover one would expect from a production messaging system. 

The transparent failover feature fails over your connection/session transparently from one node to another if the node you are connected to fails as opposed to requiring application code to handle connection exceptions explicitly.  Another key feature added is distributed destinations. Unlike some of JBoss'  competitors, JBoss Messaging supports fully logically distributed queues and topics across a cluster.

InfoQ spoke to JBoss Messaging Project Lead (Ovidiu Feodorov) and Technical Lead (Tim Fox), to ask them about their latest release as well as their thoughts on JMS & SOA in general.

InfoQ: First, congratulations on getting the 1.2.0 release out. Can you give us a quick overview of who you are and what roles you play in the JBoss Messaging team?

Ovidiu: Thank you. I am Ovidiu Feodorov, founder and lead of the project. I am leading the project since its inception in 2004. During these years, I saw the code base growing from 0 to almost 300,000 lines of code and going through two major General Availability releases.

Since we're such a small team, 3 people at the time of this interview, I don't think we're so "layered" that we can say we have very definite, non-overlapping roles and responsibilities. The team functions more like a start-up, where all of us do whatever is needed for the project to go forward. So, I am coding, I organize and participate in design meetings, write documentation, answer discussion forums and support cases, tend to wiki, teach classes, consult on-site when necessary, evangelize Messaging at user meetings and conferences and do anything that being part of such a small team requires me to do. One of the roles that I enjoy the most is keeping the team tight together, focused on our "mission", which is to write the best messaging system on the planet.

Tim: My name is Tim Fox. I've been at JBoss for about 18 months during which time I've been 100% working on messaging. Before JBoss I was one of the co-authors of the first open source JAIN SLEE 1.0 (telco application server) implementation. I'm currently the technical lead of the project which means I have responsibility for guiding the project's technical direction. In essence this entails overseeing the technical architecture and design and other issues of a technical nature.

InfoQ: How do you think this release compares with previous releases of JBoss Messaging in terms of reliability and performance?

Tim: Most of the 1.2 codebase builds on the 1.0 codebase, so we are building on an infrastructure that is already used in many production deployments around the world. We have always taken reliability very seriously but we take it further with JBM 1.2 with integration with JBoss Transactions so any XA transactional work done with JBM is now highly durable. I.e. we very strongly implement the "D" from ACID.

In terms of performance we have a performance test framework that can be run against any JMS 1.1 compliant provider and the results show our performancefar exceeds that of JBoss MQ in pretty much every area.

Ovidiu: 1.2.0.GA is the "clustered release". While 1.0.0 (and subsequently, the 1.0.x series) was a fully JMS 1.1 compliant, non-clustered messaging broker, 1.2 goes beyond the JMS specification and adds enterprise-level capabilities, such as fault tolerance and load balancing, all these while keeping it fully JMS 1.1 compliant.

The new 1.2 Messaging broker comes with fully distributed destinations, dynamic load balancing and transparent failover capabilities, no single point of failure and no single point of bottleneck, sophisticated and fully configurable message expiration handling and XA transaction recovery.

Also, 1.2 has support for pluggable transports, namely HTTP and HTTPS. To be technically accurate, this capability was actually present in the 1.0.x series as well, but only in 1.2 we fully enabled and tested HTTP and HTTPS support, plus a new performance "bisocket" transport, that allow us to simplify the administration and deal with firewalls more easily.

If I think retrospectively, I now believe that we should have named the current release 2.0, given the amount the new functionality we introduced with it.

InfoQ: How do you think this release compares with previous releases of JBoss Messaging in terms of reliability and performance?

Ovidiu: One of the major improvements of this release is that it allows for horizontal scalability: one can seamlessly add more node to the cluster, spreading processing of messages over more physical nodes. In what the performance of a single node is concerned, the original 1.0 code base underwent several waves of refactoring. We fundamentally changed the core channel mechanism, which contains the main message delivery path. While 1.2.0 is very performant to start with, there is room for a great amount of optimizations. This is what 1.2.1, 1.2.2, 2.0, 3.0 ... are for.

We're very proud of our performance framework, and the concept of "performance tests" we plan to employ to track evolution of performance metrics across releases. The same way a functional test that goes off tells you that there's a problem with the implementation backing up the API, a performance test would trigger the alarm bells if we somehow break the implementation and make it less performant than in the previous release. You can take a look at the concepts behind our performance framework and get an idea how to use it, HERE.

In what reliability is concerned, the "clustered" release is radically different from 1.0.x series. For an 1.0.x broker, a failure would mean that an administrator would need to restart the server instance and the client code detect the failure, look up a new connection factory, re-create the connection, and so on. Not so in 1.2. The failure is handled transparently, the client code doesn't even notices (unless it registers a special listener) that the connection failed and it was transferred to a different back-up node.

InfoQ: Most people who think about JMS and JBoss (or should that be Red Hat?) think about JBossMQ. Although popular, it had some publicized deficiencies that pushed people to other offerings. Did this lead to the development of JBoss Messaging?

Ovidiu: Yes. Back in April 2004, in the pre-JBoss Messaging days, I remember participating in a design meeting in Austin, where Adrian Brock, JBoss' Chief Scientist, Bela Ban, the JGroups founder, Ivelin Ivanov and I were discussing the "state of Messaging" and trying to take a decision whether to patch the existing JBossMQ or just scrap it and go for a completely new implementation. At that time I was too new with JBoss to have perfected my technique of "design by photography", so I don't have a record of that meeting, but I can show you the next best thing, snapshots of our design diagrams, taken in Austin in December 2004, where together with Adrian Brock we did the first review of the new design. They are available here: For the curious, a more or less complete illustrated history of JBoss Messaging design meetings is available here:

Back to the original JBossMQ vs. Messaging question, we came to the conclusion that JBossMQ has two fundamental limitations. One is that the HA capabilities were an afterthought for JBossMQ. SpyderMQ, the open source project JBossMQ is based on, is an essentially non-clustered broker. The second limitation was related to the threading model and the overall design of the non-clustered broker itself, which led to performance limitation in certain high load usage scenarios.

At that time we reckoned that working around or patching these fundamental problems was more trouble than just starting it cleanly from scratch, and that was the decision that led to the birth of JBoss Messaging. And here we are, exactly three years later, after two major Messaging releases. It's up to our users to judge whether the decision was correct or not.

InfoQ: How does JBoss Messaging compare to JBossMQ?

Ovidiu: JBoss Messaging is a JMS broker designed from scratch with enterprise capabilities in mind. The very first elements of design were based on the assumption that Messaging is a fully clustered, load balanced and highly available broker. JBossMQ, as I said before, started as a non-clustered JMS broker, whose HA capabilities were literally "bolted on" in the form of a HA singleton mechanism.

While a JBoss Messaging destination (be it queue or topic) "lives" in different address spaces, and spreads multiple virtual machine and physical boxes, offering seamless load distribution and transparent failover, all JBossMQ destinations are crammed on a single VM. If that VM happens to fail, the HA Singleton mechanism starts another (unique per cluster) JBossMQ instance on another cluster node and recreates all destinations on that node. Clients are not being offered the luxury of a transparent failover process, they need to detect failure by themselves and recreate connections.

JBossMQ essentially is a "single point of failure", somehow mitigated by the fact that the broker can recover from failure, and a "single point of bottleneck". JBoss Messaging has none of these limitations.

InfoQ: How relevant to SOA do you think JMS is, particularly with Web Services appearing to be the preferred deployment platform?

Ovidiu: MOMs have been around for a long time, are here to stay as means of integrating loosely coupled systems. Historically speaking, there was the file transfer, the database, the RPC systems and the MOMs. Lately, Web Services came and joined the the list. All of these paradigms have their advantages and disadvantages, and the decision of using one, or another, or a combination thereof usually comes after a elaborate act of balancing.

What Web Services have and messaging systems don't, is standard-level interoperability. JMS, as a standard, does not provide for interoperability. The JMS specification doesn't go to the extent of specifying a wire format for a message, so each vendor has the liberty of introducing its own format and optimize the implementation the way it sees fit. That is not to say that bridges cannot be written, but they are not a given, they don't come out of the box. There's a glimmer of hope in this direction, though. AMQP, a new messaging protocol pushed, between others, by Red Hat, is proposing to solve the interoperability problem. Let's see where that goes.

That being said, both Web Service systems and MOMs have their place and specific application domains that they fit best.

InfoQ: You mentioned Red Hat's involvement in another messaging protocol called the Advanced Message Queuing Protocol (AMQP). Is there any overlap with JBoss Messaging?

Ovidiu: JBoss Messaging is a broker implementation. AMQP is a specification. An implementation can be always extended to implement a specification, if it makes sense. After examining the AMQP specification in detail, I can only comment that the server side model introduced by the specification fits like a glove over the JBoss Messaging internal architecture. What this means, practically, is that when AMQP becomes final (it is currently in 0.9), JBoss Messaging will implement it and play nicely (read: interoperate) with other AMQP implementations.

Tim: AMQP is certainly an interesting new protocol and we are definitely keeping an eye on it. I believe the basic principles are sound, particular with respect to wire format compatibility which doesn't currently exist between JMS providers. Right now the specification is definitely still a work in progress with some omissions e.g. XA transactions and a lack of clear mapping between JMS and AMQP in order to allow interoperability of JMS providers built on top of AMQP. I believe these are currently being addressed. My view is it's not quite ready for prime-time but more than likely will get there over the next year or so.

Rate this Article