This is my first blog ever. I am not literary inclined so I never felt the urge to describe in a public my latest shopping journey or what I think about my friend's hypothesis that mystical experiences are a byproduct of our reptilian brain. However, I do think that short, well written essays on a project's features do a lot of good to users. They have a first hand, straight from the source report on things they are interested in. Now only if programmers would make good writers. It's not a coincidence I decided to start writing this article now. I waited until we got a stable Messaging release out, and this happened two weeks ago, on March 31st 2006. So here we go.

 

Messaging is the result of almost 2 years of efforts of a permanent team of one, then two people. Currently, we are somewhere close to 200K lines of code, 2000+ functional tests, and a brand new performance framework we use to track performance metrics across releases. The best part is this is only the beginning. The project is a well tuned machinery that just started to crank out feature after feature. You have a complete visibility over it. You can access its roadmap, its design discussion forum and design wiki, obviously its user forum and user wiki page. Details go as deep as design meeting documentation. We're proud to talk about these, so I couldn't help it. But I also realize there's a good chance these details are most likely irrelevant to you, the user. At this point you are probably thinking "This is all good, but what Messaging can do for ME?"

 

The 1.0.0 bundle available for download contains a fully compliant JMS 1.1 provider implementation. The compliance is tested with Sun Microsystems J2EE Compatibility Test Suite. JBoss Messaging 1.0.0 is more performant, more reliable and better supported than JBossMQ. I will briefly address these issues here, one by one, and I will follow up with separate articles on performance considerations, configuration and compatibility with JBossMQ, POJO Message Driven Beans and clustering roadmap.

 

JBoss Messaging is more performant than JBossMQ and we've got charts to prove it. To get here, we've overhauled the core threading model, the persistence mechanism, the transaction support and the serialization behavior. Overhaul is actually not a good word, since we've actually written most of the components from scratch. The whole core architecture is new, based on primitives such as Receivers, Channels and Routers that connect to form complex topologies. The messaging core is JMS agnostic, a fully distributed and transactional messaging transport system. The JMS personality of the server is given by a JMS facade, while other facades are also possible. These subjects deserve a separate article, which is will try to produce, shortly.

 

A step forward from the previous development model is that these performance improvements are actually measured and tracked across releases. Together with the main product, we also grew a performance framework, which makes possible to define performance tests in XML and automatically generate performance graphs. The whole process is automated and can be incorporate in a "CruiseControl" type of mechanism. What this means for you is that we have the tool to make sure that each release only gets better, performance wise. Any performance degradation is detected and addressed during the pre-release cycles. When you report problems, you will be able to send us a performance test configurations, which we can potentially replicate in our labs.

 

I also said that JBoss Messaging 1.0.0 will be better supported. By no means I wanted to imply that our support team does not do a good job at supporting JBossMQ. They are a brilliant support team and do wonders with the code base we have. However, that code base entered maintenance mode long time ago, which means no new features are added to it. The programmers that contributed to it are now busy with other projects. In Messaging's case, the people who wrote 100% of the code base are now also the third level of support, and they really want this project to succeed. For you, this means you will get direct support from the team that wrote virtually every line of code in JBoss Messaging.

 

We're really paranoid about QA, to tell you the truth. The capital sin of the Messaging project is "is deleting, commenting out or otherwise modifying a semantically valid test". It is written there, in our Guidelines for Committers. Our functional testsuite contains about 2014 functional tests as we speak. We also have (or plan to add soon) integration tests, external JMS compliance tests, TCK, stress tests, soak tests, smoke tests. Lots of tests, really, and they run continuously and ring alarm bells every time we screw up something.

 

So, you may wonder, with all this heavy artillery in place, how come 1.0.0 release wasn't flawless? Where those minor annoyances reported on the user forum came from? Why is 1.0.0 not perfect? Well, this is by design, as odd as it sounds. Given the limited resources, we took the decision to release something that passed all our tests, and rely on you to make it perfect. We're developers, we're conditioned by our work and our direct contact with our development environment and maybe we subconsciously take decisions that indirectly protect the "baby" from looking bad, even when we write the most sophisticated tests. Or, simply, we just forget things. This is almost a textbook example: before release, we "smoke tested" the release with all 4.0 JBoss instances we decided to support. My "developer conditioning" made me take the AS source code, compile it and create my JBoss test instances, and all smoke tests passed. However, not even a second I thought to run the smoke test on an "installer-generated" JBoss instance, which is actually what any user would do. There are subtle differences between an "extracted" and an "installer-generated" installation, and Messaging stumbled with an "installer-generated" instance. The solution: fix the implementation (5 minutes), add the "installer-generated" instances to the smoke test fixture (30 minutes) and countless hours of future smoke testing, but hey, tests can be run on dedicated machines, and machines to run tests are cheap ...

 

The morale of the story is that we're trying to build a convergent system, that will prevent us, simple mortals, from making again mistakes that we have already made. That's also why we need your input, we need you to download the release, use (and abuse) it and feed your bug reports, comments and suggestions back. We're half joking that our final objective is to make Messaging the best messaging system on the planet. We will certainly do all we can to get there, and you can help too.

 

The big absent in 1.0 is the clustering capability. Actually, I would say that the "production-quality" clustering is absent. If you take a look at the source code, you will notice a lot of "distributed" classes. Messaging was written from ground up with clustering in mind, and the foundation is laid out already and it's in CVS. It needs more work, of course. We are planning a big Clustering design session in Austin at beginning of May, to decide on the latest details and prepare the final offensive towards 1.2. By that time, we will also have the precise release date, but we don't think this will be sooner than Q3.

 

I cannot even think to conclude my first blog about Messaging without mentioning the team that made this possible. The Master of Synchronization and the Czar of Race Conditions, Tim Fox, is the heavy lifter of the team. If I would write down in detail all wiring and features he contributed to the project, I would probably need to stay here until tomorrow, so I would just briefly mention synchronization and threading issues, transaction and XA implementation, locking, scalability, optimizations, AOP stack implementation, channel paging and many others. I hope Tim will start writing his own blog pages on these subjects soon. Adrian Brock is actually the "father" of Messaging, he laid out the project's fundamentals, long time ago, and all we did was just to follow in his footsteps. Luc Texier gave us a huge hand and basically wrote the entire user documentation in a critical moment of the project. Alex Fu constantly contributed along the way, and Aaron Walker jumped to help us when we needed it most. Also thanks to Tom Elrod and Clebert Suconic who assisted us when we were almost brought down by Remoting or Serialization problems.

 

We just started on the path to world domination. We want to work together with YOU to make JBoss Messaging better and better, until we finally reach the inevitability: Messaging will be the fastest, more reliable and more scalable messaging system on the planet. And as I always say after this sentence, I am only half joking.

More articles soon to come:

• "JBoss Messaging Architecture. Why is JBoss Messaging better than JBossMQ?"
• "JBoss Messaging Configuration. The truth about compatibility with JBossMQ."
• "JBoss Messaging and POJO Message Driven Beans"
• "Future plans. When can I use Messaging Clustering?"