JBoss HornetQ 2.0.0.GA Released with (Optional) Native Linux Journal for Improved Performance
HornetQ is an open source community project to build a multi-protocol, embeddable, ultra high performance, clustered, asynchronous messaging system. HornetQ can be used to provide messaging functionality from the smallest of applications to empowering the largest of enterprise messaging topologies.
With the initial announcement of HornetQ, JBoss had explained about the relation between HornetQ and JBoss Messaging 2.0:
During its development over the last couple of years the HornetQ code-base was worked on under the name JBoss Messaging 2.0 We decided to rename it and separate it as an independent project since it differs in a many ways from JBoss Messaging 1.x and we did not want to confuse the two, quite different, systems. The vast majority of the code base of HornetQ is different to the code base of JBoss Messaging 1.x. So, what happens with JBoss Messaging now? JBoss Messaging 1.x continues to be known under the name of JBoss Messaging and the project is now in maintenance mode only, with all new messaging development happening on the HornetQ project.
HornetQ can be run as a stand alone messaging server, or can be integrated in the JBoss Application Server:
HornetQ has zero dependencies on any JBoss Application server components, in fact HornetQ core has zero dependencies on any libraries other than the core JDK and Netty! Although HornetQ can be easily integrated in JBoss Application Server as the JMS provider, it can also be run as a fully functional completely independent standalone messaging server outside of JBoss Application Server, or it can be instantiated in your dependency injection framework of choice, e.g. Spring or Google Guice. You can even embed HornetQ directly in your own applications.
JBoss claims that its custom journal for message persistence has a much higher performance, than other competitive solutions that use relational databases for persistence:
HornetQ provides message persistence using its own built-in, high performance journal. HornetQ has no dependency on clunky, slow, relational databases for persistence. The journal is a unique piece of technology that automatically detects if running on Linux and uses Linux Asynchronous IO (AIO) via a native code layer for astonishing performance. If AIO is not available seamlessly falls back to using Java NIO, so will run seamlessly on any Java platform.
Since HornetQ doesn't use a database for persistence, users of the old JBoss Messaging product that want to migrate an existing queue will need to use a JMS Bridge:
To migrate queue/topic data, I'd recommend using the JMS Bridge to consume the messages from the old server and forward them to the new server. This technique should work with any two compliant JMS providers.
HornetQ is scheduled to be the default JMS provider in JBoss Application Server 6 and JBoss aims for HornetQ version 2.1 to be cloud enabled by implement a REST style API for interoperable messaging:
Define a RESTful interface for messaging that can be accessed via plain old HTTP. REST interfaces are likely to be become the defacto interface style for the cloud. Implementing a REST messaging interface is crucial for us to achieve our goal of being a cloud-enabled messaging provider, and the cloud messaging provider of choice. The RESTful interface is likely to be an implementation of the REST messaging specification from the REST-* project.
The project wiki holds a large list about the features that are present in 2.0.0.GA.
HornetQ is licenced using the Apache Software License v2.0 and planned to be fully supported by Red Hat as part of a JBoss Enterprise Application Platform subscription, in the near future.
You can find more information about HornetQ on the project web site and wiki. There is also a short guide that will help you to take HornetQ for a tet drive in just a few minutes.