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.

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 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.

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.

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.

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.