What Java version does HornetQ require?

HornetQ 2.0 will run with Java 5 or later. HornetQ will not run with earlier versions of Java (e.g. Java 1.4).

We recommend using Java 6 for the best performance.

From HornetQ 2.1, the server requires Java 6 or later. We provide a Java 5 client if required for legacy client apps that require Java 5.

We do most of our testing with Sun JVMs.

What protocols/APIs does HornetQ understand?

HornetQ can currently be accessed using the JMS 1.1 API or using HornetQs optimised core API.

From HornetQ 2.1, we provide a native STOMP implementation, so HornetQ can be used with a range of non Java clients.

HornetQ also can be accessed via websockets from inside a browser.

HornetQ also supports a RESTful messaging interface over HTTP.

We are also considering adding XMPP support, and a comet-style interface.

I'm doing my benchmark and HornetQ doesn't perform well. Why is that?

It's been quite common users performing their micro benchmarks without fully understanding how systems will achieve performance on enterprise systems.

When you send persistent messages, you are required to perform a sync on the disk before you can deliver any messages or send a response back to the client. In certain cases the client will be waiting a network round trip also, so a single producer case will be limited by the sync capacity and round trip capacity of your hardware.

HornetQ (as many other enterprise systems) will scale up to multiple clients performing multiple requests in a single request to disk and network, making a better usage of the hardware resource.

So, for a proper benchmark you need to be aware of the behavior used by the use case you are dealing with.

I don't intend to list all the details here, but just to give an overall idea:

• Non Persistent Messages : Everything is asynchronous by default. This should be the fastest case
• Persistent Messages: Both the send and the persistence are synchronous. The client will send a message, wait for a round trip and the sync on disk. You need several clients to measure overall server's performance on this case. (Scalability).
• Transaction Messages: The messages are sent without any sync and totally asynchronous. However the commit or prepare will require a round trip.

I'm comparing HornetQ to an XYZ software and the performance is below what's been advertised.

It's also a common case users comparing oranges to bananas.

HornetQ is strict as possible out of the box in regard to syncs, and we still provide excellent performance with these settings.

Some messaging servers however will perform poorly when increasing sync requirements. They may appear faster when used their configs out of the box, what means you are comparing oranges to bananas.

HornetQ also supports more optimistic syncs if that's what you need. Look at the user manual for the journal configuration options. (and on the ConnectionFactory for sync options on message sending).

Can HornetQ be used with non Java clients, e.g. C++ clients?

Yes, from HornetQ 2.1 we ship with a native STOMP implementation. This allows any of the many STOMP clients to be used with HornetQ. STOMP clients are available in many languages.

HornetQ REST can be accessed by any client capable of sending HTTP requests and parsing responses.

Should I create new JMS connections, sessions etc every time I send or consume a message?

Please see this article

Should I cache my own JMS connections, session, etc?

Please see this article

Is it safe to use the Spring JMSTemplate with HornetQ?

Please see this article

Running a HornetQ cluster using discovery doesn't work?

Please see this article

The HornetQ clustering examples don't work?

Please see this article

I can't make connections to my remote HornetQ server from another server or a client

Make sure you have specified a host name or ip address for your acceptor(s) to bind to. If you don't specify one then it will default to localhost, and of course, that won't be visible to remote machines!

Another possibility is you have bound your acceptor to a hostname, and that host does not resolve to an ip address on the client box from which you are trying to make the connection.

See the user manual, chapter "Configuring the Transport" for more information on this.

Messages are getting out of order after redelivery

HornetQ will always guarantee order of delivery at the producer level if you use a single consumer per queue without selectors.

When you have multiple consumers on the same queue, redelivered messages will be sent back to the top of the queue and other consumers may get the message first.

Messages on the buffer will be also sent back to the top of the queue in case of redelivery. You can avoid this behavior by disabling buffering on the consumer however this option would certainly have performance implications.

Look at Message Groups for more information.

And also 11.1.32. No Consumer Buffering