codesmell.org

after ActiveMQ let us down the third time (rant to follow), it was time for alternatives. as i am a strong believer in OSS and the budget is tight these days, i´d love to stay in that ballpark instead of just buying SonicMQ.

so looking for alternatives i came across the recent announcement of HornetQ formerly known as jboss-messaging. even though i am not particularly known as a friend of jboss due to prior experiences with their AS, i chose to take that hornet for a flight. here´s what it turned out to be:

Arrival

download, done. as easy as that. well almost.

certainly you want to take a look at HornetQ-configuration.xml. there is binding to non-localhost and a few options like redelivery-delay, redistribution-delay and rates for consumer and producer to take care of.

if you´re on a linux env, you might want to use their AIO stuff, which is explained in great detail here.

Pre-Flight Preparation

as a happy maven user it took me a while to find out what libs i actually needed as a minimum to use HornetQ as JMS Implementation. just afterwards i discovered this nice blog article that gives it all.

basically it is:

 XML | 
 copy |
?
 
   <!-- if you like that API better than JMS -->
   <dependency>
      <groupid>org.HornetQ</groupid>
      <artifactid>HornetQ-core-client</artifactid>
      <version>2.0.0.BETA5</version>
      <scope>compile</scope>
   </dependency>
 
   <!-- the actual JMS Impl -->
   <dependency>
      <groupid>org.HornetQ</groupid>
      <artifactid>HornetQ-jms-client</artifactid>
      <version>2.0.0.BETA5</version>
      <scope>compile</scope>
   </dependency>
 
   <!-- transport layer -->
   <dependency>
      <groupid>org.HornetQ</groupid>
      <artifactid>HornetQ-transports</artifactid>
      <version>2.0.0.BETA5</version>
      <scope>compile</scope>
   </dependency>
   <dependency>
      <groupid>org.jboss.netty</groupid>
      <artifactid>netty</artifactid>
      <version>3.1.0.GA</version>
   </dependency>
 
 

sidenote: i don´t get why HornetQ-transports for instance does not declare a dependency to netty. unfortunately with any jboss product, you have to dig for a particular foggy combination of jars that work together. (sorry for that obvious reference to hibernate )

Tower

there is none. ok, the HornetQ server exposes itself heavily via JMX, but you cannot expect anything similar to ActiveMQ in terms intuitive usability or comfort. on the other hand, using (and understanding) the JMX-exposed API gives you much more power than what the average JMS server provides.
what we (my company) did, was to create a simple webapp considerably equal to what the ActiveMQ admin-webapp is (without the screwing up part) to manage queues/topics, messages and monitor the nontrivial processes that JMS provides in terms of redelivery, dead-letters etc…

SCREENSHOT TO FOLLOW

there also is hermes, but we never got it running with HornetQ in a way that we could manage queues and move messages.

Choose Gangway

HornetQ is a JMS provider, yes. and even though i am not a fan of using a proprietary API over a standardized one, you might want to take a look at their direct API to messaging. it is a slightly different perspective (no difference between queue and topic) to JMS, but it is a little simpler in some corners.

we can afford going that way, because we have an abstraction on top of that, that protects our application code from a dependeny on a particular API, anyway.

Lift-off

first of all, you can easily embed HornetQ server into any app. beside tests, the usecase we had for that was the admin application mentioned above. this is not too important, but very handy as you can easily bundle these things together.
using the client API, as well as the JMS API is as trivial as you would expect. the only thing you might want to know is their way of implementing streaming of big messages.

Heavy Lifting

some people say, that sending big messages over JMS is terribly wrong from a conceptual perspective. well, it depends. we do have some usecases, where a message contains a job that really carries quite some data. i wont enter the discussion, if this job should better be persisted and just being triggerd by a small JMS message, but one thing is for sure: it is much easier this way.
so what am i talking about when i say “quite some data”? significantly less than 5mb. while this is not considered “big” in any other context, an ActiveMQ faild us with OOMs when recieving such a message even though he had 512m of heap.

any possible replacement for ActiveMQ for us had to demonstrate a reliable operation with messages that go up to 30mb.

HornetQ delivered quite good here. be it the JMS API or their own (supposed to be simpler) API to messaging, you can easily stream data into messages. the server then streams those messages into a large-messgae directory and the cake is eaten. this is not particularly reocket science, but our bad experience with ActiveMQ makes me emphasize this:
HornetQ copes with messages of any reasonable size!

in fact, we chose to use this pattern for any message we send (ignoring the performance resulting from the extra handling of this kind of message) in order to be safe and relax on mem requirements as much as possible.

Landing

we replaced some ActiveMQ servers in production environments by hornets and since then, we did not touch them. we set up (very frequent) nagios roundtrip tests and the like, and hornet did not let us down once.

even though i am not particularly known as a friend of jboss, i am grateful of this being not only open source but also isolated from jboss AS and the rest of their (sometimes bloated) ecosystem.

Final words

the advanced configuration is a little weird here and there and lacks documentation. it has a bunch of things, that do not provide value FOR US, like throttleing.
in operational tests, we discovered some weird (but reproduceable) behaviour when ungracefully stopping HornetQ. some messages were safe, but no longer moveable to another queue (brings NPE). we suspect this to be a beta issue that´ll be taken care of.

apart from that: HornetQ is easy to get started with, reliable, reasonably fast, highly configurable and (once you got the API) flexibly managable.

it instantly is a major player in OSS JMS provider market and, if you happen to have requirements similar to ours, a very good choice.