What is HornetQ?

HornetQ is an open source project to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system.

HornetQ is designed with usability in mind.

HornetQ is an example of Message Oriented Middleware (MoM)  For a description of MoMs and other messaging concepts please see the chapter 2 of the user manual "Messaging Concepts".

HornetQ takes over from JBoss Messaging as our premier JMS implementation.

Why a Hornet?

Hornets are fast, angry and have attitude, with a sting in their tail.

You don't mess with the hornet.

Also they make great logos.

What's the relation between JBoss Messaging and HornetQ?

During most of its development the HornetQ code-base was known as JBoss Messaging 2.0.

We decided to rename it and spin it off as an independent project since it differs in a great many ways from JBoss Messaging 1.x and we did not want to confuse JBoss Messaging 1.x with JBoss Messaging 2.x.

The vast majority of the code base of HornetQ is different to the code base of JBoss Messaging 1.x.

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.

Can I get support for  HornetQ?

HornetQ will be integrated into Red Hat and JBoss products and support provided through our usual subscription model.

How is the HornetQ source licenced?

The HornetQ source is licenced under the Apache Software License version 2.0 with the exception of a very small number of files that we were unable to relicence which remain licensed under the LGPL.

We aim to provide alternative ASL licenced versions of those files over time.

The ASL 2.0 has fewer restrictions on use than the LGPL, thus providing fewer barriers to adoption. We want HornetQ to be adopted as widely as possible so that's why we chose it.

How is the HornetQ documentation licenced?

The HornetQ documentation is licenced under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA").

An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/.

Why did HornetQ start at 2.0.0?

The HornetQ code-base was originally known as JBoss Messaging 2.0 during most of its development.

For continuity we decided to continue the JBoss Messaging version numbering in HornetQ.

Who develops HornetQ?

HornetQ is an open source community project and we encourage and welcome contributors to help us and get involved.

Red Hat Middleware Division (a.k.a. JBoss) also provide a small team who are employed to work on HornetQ development.

What are Red Hat's plans for inclusion of HornetQ in JBoss and Red Hat's products?

Going ahead, HornetQ will be integrated into JBoss and Red Hat products.

Is HornetQ tightly coupled to 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.

Is HornetQ a stand-alone messaging system?

Yes, HornetQ can be run as a fully functioning stand-alone messaging server quite separate from JBoss Application Server.

Can HornetQ be integrated in JBoss Application Server?

Yes, HornetQ can be integrated seamlessly into JBoss Application Server version 4.x, 5.0 or later using instructions provided in the documentation.

JBoss Application Server 6 or later comes with HornetQ pre-installed as default JMS provider.

Does HornetQ have a strategy on cloud computing?

We are aiming for HornetQ to be cloud enabled, and want it to be the messaging provider of choice in the cloud. Most likely this will require HornetQ to implement a REST style API for interoperable messaging, which is on our roadmap.

Why the backup node is not being activated after the live is gone?

At the time this FAQ is being written (2.1.0) the backup will only be activated after the first connection arrives on the client.

If nothing is connected to backup, nothing will be activated.

This is being changed on 2.2.0. So this will depend on what version you're using at the time of reading this FAQ.