18 February 2010

HornetQ - fast with nice features?

HornetQ Stings the Competition in Peer-Reviewed Benchmarks | Javalobby

So not only is it supposed to be fast, but if you look at its feature list, it has some nice enterprise features:

  • Very high performance journal for message persistence
  • Topic hierarchies.  Also known as "topic wild-cards".  The idea here is that you can create a topic subscriber using a wild-card, e.g. you could create a consumer on newsfeeds.uk.* then it will receive all messages sent to newsfeeds.uk.sport and also newsfeeds.uk.culture.
  • Dead letter addresses.  A dead letter address is where a message gets sent when it can't be delivered after X number of retries.  Dead letter addresses are highly configurable in HornetQ - they can be configured either globally or on subsets of addresses individually.  Also they need not only represent a queue. Dead letter addresses can represent addresses at which there may be multiple subscribers, or diverts.
  • Producer flow control.  HornetQ provides a credit based producer flow control mechanism to prevent clients overwhelming a server with messages.
  • Consumer flow control.  HornetQ provides a credit based consumer flow control mechanism to prevent client consumers from being overwhelmed with messages sent from a server.
  • Send acknowledgements.  Register a listener to get acknowledgements that messages sent asynchronously have arrived and been processed on the server.  This gives the same arrival guarantees as sending a JMS message in blocking mode but at much higher peformance since it is asynchronous!
  • Last value queue.  This is a special queue which only keeps the most recent copy of a message with a certain header.  E.g. useful for stock prices where you're only interested in the latest price.
  • High performance core bridges.  Core bridges can be used to connect any two HornetQ instances.  Bridges can be optionally configured to only forward messages which match a particular selector query (like SQL 92 syntax).
  • Bridges can forward preserving destination or to a different destination.  Bridges have a transformation hook point where you can plug in message transformation (e.g. smooks).  Bridges are resilient and cope with connection failure, automatically retrying etc as appropriate.  100% once and only once delivery is guaranteed with a bridge without having to resort to more heavyweight solutions such as JTA (XA).
  • Server clusters.  You can configure groups of HornetQ servers into clusters.  Messages sent to a node in a cluster are automatically load balanced across all the matching consumers in the cluster, even if the target node is several hops away, and number of consumers on remote nodes is taken into account.
  • Automatic, fast, client failover.
  • Replication of data store.
  • Clustered request-response.  Send message with reply-to set, message is processed on any node of the cluster and reply is sent back to the original node.
  • Message grouping.  Message grouping allows you to guarantee that all messages of a certain type are processed serially by a single consumer.  This is done by adding a special property to the message. All messages with the same value of the property will be processed by the same consumer.  This also works across the cluster!