Here's a listing of the features available in HornetQ.

For a full description of all features and how to use them, please consult the user manual.

Features in 2.0

• JMS 1.1 API
  
  HornetQ provides a fully JMS 1.1 compliant API. The whole shebang - connections, session, producers, consumers, durable subscriptions etc.
  
  We won't list all the JMS features here as separate features. You can assume that if it's in the JMS 1.1 specification, then HornetQ provides it.
  
  
• Optimised core API
  
  HornetQ also provides its own client side API which you can choose to use instead of JMS.
  The HornetQ core API provides all the power of JMS without some of its complexity. The core API also provides some features like "send acknowledgements" which are unavailable using the JMS API.

• Seamless integration into JBoss Application Server
  
  HornetQ can easily be installed as the JMS provider in JBoss Application Server 5.0 or later.
  
  Simple instructions are provided in the distribution showing you how to do this. Later releases of HornetQ will be the default JMS provider in JBoss Application Server 5.0, i.e. it will be pre-installed and you won't have to install anything manually.
  
  
• Standalone server
  
  HornetQ can also be run as a 100% standalone messaging server with no dependencies on JBoss Application Server.
  
  This is of interest if you want messaging, but don't want an application server.

• Pure POJO design
  
  HornetQ is architected as a set of Plain Old Java Objects, it can therefore be run in JBoss Microcontainer, Spring, Google Guice or embedded in any third party product and instantiated directly.
  
  HornetQ core has *zero* thirdparty jar dependencies. It only requires standard JDK classes to run.
  
  
• JCA adaptor
  
  HornetQ provides a fully functional JCA adaptor that can be used in any JEE compliant application server to integrate HornetQ so it can be used for consuming messages via Message Driven Beans (MDBs), or for sending messages in Enterprise JavaBeans or servlets.
  
  
• Fully JTA capable (XA)
  
  We provide a fully functional XAResource implementation. HornetQ can then be enlisted in any JTA transaction acording to the normal JTA semantics.
  
  
• Very high performance journal for message persistence
  
  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.
  
  Watch our competitors weep when they see it fly
  
  
• Fully pluggable transport system
  
  The HornetQ low level transport is completely pluggable. We define a Service Provider Interface (SPI) that you can implement in order to plug-in a new provider.
  
  HornetQ ships with an invm transport implementation for when both the client(s) and server are in the same Java virtual machine, and also an implementation using JBoss Netty for high performance operation when client(s) and servers are remote.
  
  We use Netty to provide the TCP, SSL, HTTP and Servlet transports (see below).
  
  
• TCP transport
  
  Clients and servers can be configured to communicate using un-encrypted TCP sockets
  
  
• SSL transport
  
  Clients and servers can be configured to communicate using encrypted TCP sockets using the Secure Sockets Layer (SSL).
  
  
• HTTP transport
  
  Clients and servers can be configured to communicate messaging traffic tunnelling over HTTP requests and responses. This can be useful when you are running through a firewall.
  
  
• Servlet transport
  
  Clients and servers can be configured to communicate messaging traffic tunnelling over HTTP requests and responses. The requests are served using a servlet that is hosted in a servlet engine. The servlet then reroutes the requests to the messaging server running behind the firewall.
  
  This differs from the HTTP transport in that it can allow you to serve messaging traffic from some other servlet engine / web server which already is serving other JEE applications. With the HTTP transport JBM acts as an HTTP server in its own right.
  
  
• In-VM transport
  
  If client(s) and servers are running in the same Java virtual machine, then can be configured to us the In-VM tranport which creates direct connections in code.
  
  
• JMX management API
  
  HornetQ provides an extensive management API, that can be accessed using JMX.
  
  This management API is also available using a standard JMS connection, also by sending and consuming messages to and from a special management address.
  
  
• Management over a core connection
  
  The full management API is also accessible just using a standard core connection, by sending management messages to a special address and consuming their results.
  
  
• Management over JMS connection
  
  This management API is also available using a standard JMS connection, also by sending and consuming messages to and from a special management address.
  
  This is over and above the standard functionality available in the JMS 1.1 API which does not define a management API.
  
  
• Management notifications
  
  Management notifications are messages that get sent to a special address when things happen in the server, like a consumer is created, a queue is deleted etc.
  
  You can subscribe to them using the normal semantics for message subscription. Notifications can piped to arbitrary adresses, filtered etc.
  
  
• Message counters
  
  HornetQ message counters allow you to see a history of the messages that arrived in your queue over time. With several metrics above and beyond a simple message count.
  
  
• Huge message support
  
  Send and receive multi-gigabyte messages fully reliably and transactionally even though your server might be running in only 50MiB of RAM!
  
  We have tested up to 8GiB but theoretically you should be able to send / consume messages up to 2^63-1 bytes in size, assuming you have sufficient disk space, which is quite unlikely .
  
  
• 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.
  
  
• Configurable expiry queues
  
  An expiry address is where a message gets sent when it expires.
  
  Expiry 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. Expiry addresses can represent addresses at which there may be multiple subscribers, or diverts.
  
  
• Configurable message buffering
  
  Consumers can be configured to buffer messages on the client side to give optimal performance. This can also be disabled altogether to give deterministic distribution of messages in a queue with multiple consumers.
  
  
• Producer flow control
  
  HornetQ provides a credit based producer flow control mechanism to prevent clients overwhelming a server with messages.

• Producer rate limited flow control
  
  Also, on a per producer basic you can specify the maximum rate, in messages per second, that a producer is allowed to send messages at.
  
  E.g. you could specify specify 1000 msgs/sec and the producer will never send messages faster than that.
  
  
• 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.
  
  
• Consumer rate limiting
  
  Also, on a per consumer basic you can specify the maximum rate, in messages per second, that a consumer is allowed to consume messages.
  
  E.g. you could specify specify 1000 msgs/sec and the consumer will never consume messages faster than that.
  
  
• Queue memory limitation
  
  A maximum in memory size for a queue can be configured (or for a set of queues).
  
  There is a configurable policy on reaching maximum size.
  
  Either HornetQ can be configured to transparently page messages to disk and keep accepting more or to drop messages.
  
  This allows HornetQ to support virtually unlimited queue sizes while the server runs in limited RAM.
  
  
• Pre-acknowledge mode
  
  With pre-ack mode, messages are acked before delivery, thus avoiding having to ack from the client side and reducing the overall traffic on the wire.
  
  Can give better performance e.g. with transient messages where you don't mind if a few get lost if failure occurs (e.g. stock prices).
  
  
• Blocking and non blocking sends
  
  HornetQ can be configured to either send messages blocking or non blocking. With a blocking send the call to send() will not return until the message has reached the server and a response has been sent.
  
  This can be configured individually for both persistent and non persistent messages.
  
  
• Programmatic creation of connection factories
  
  Connection factories can be created programmatically on client side.
  
  You are not limited to looking up connection factories via JNDI as per JMS.
  
  They can be instantiated directly allowing you to remove JNDI from the equation if it is not available or you do not want to use it.
  
  
• Programmatic creation of JMS destinations
  
  JMS queues and topics can be created programmatically on client side.
  
  You are not limited to looking up JMS destinations via JNDI as is normal.
  
  They can be instantiated directly allowing you to remove JNDI from the equation if it is not available or you do not want to use it.
  
  
• Generic JMS-free core API.
  
  HornetQ is architected as a completely JMS agnostic design, with functionality well above and beyond JMS.
  
  JMS is added as a thin adaptor layer on the client side.
  
  Consequently users, if they wish, can use our generic client side API directly. This is simpler yet more powerful than using the JMS API.
  
  
• 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!
  
  
• Scheduled messages
  
  Send message specifying time in future when you want message delivered. The message won't get delivered until then.
  
  
• Highly configurable queue security
  
  Queue security based on hierarchical wildcard matching.
  
  E.g. I can say all queues with name "queues.*" require these permissions, and all queues with name "queues.myqueue.tim*" require these other permissions.
  
  
• Highly configurable queue attributes
  
  Queue attributes based on hierarchical wildcard matching.
  
  You can define queue attributes such as maxium size, durability etc. based on wildcards.
  
  E.g. all queues with name "queues.myqueue.tim*" are durable and maxsize=1000 but all queues with name "queues.*" are non durable and maxsize=unlimited
  
  
• Diverts
  
  Diverts allow you to divert messages from one address to another.
  
  You can define arbitrarily complex "routing tables".
  
  E.g. You can define a divert to siphon a copy of all message sent to address "queues.orderqueue" to another address "topics.thecore".
  
  Diverts can be exclusive - i.e. messages are diverted *instead of* going to their normal address, or non exclusive which means messages are diverted *as well as* going to their normal address.
  
  
• Active message expiration
  
  Not only does HornetQ guarantee it will never deliver an expired message to a consumer, it also has a message expiry reaper thread runs on the server and inspects queues in memory, weeding out expired messages and sending to expiry queues if appropriate.
  
  
• Queues with static selectors
  
  Queues can be deployed with a selector filter expression (SQL 92 based). This means only matching messages will be accepted in the queue.
  
  
• 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.
  
  
• Message priority
  
  Message priority is supported both on server and client. Higher priority messages are delivered first.
  
  
• Client runs in jnlp sandbox or applet
  
  The HornetQ client can run in a restricted security environment.

• Extended core filter syntax
  
  HornetQ provides an extended core message filter syntax, in which other attributes e.g. message size can be used in selector expressions.
  
  
• UDP discovery of cluster on client side
  
  Clients can be configured to discovery a cluster of servers to connect to using UDP, which means clients don't need to be pre-configured with the specific connection details of all servers in the cluster.
  
  
• Auto-reconnection of clients
  
  Clients can be configured to auto-reconnect to servers when they become unavailable, e.g. due to a temporary network problem or perhaps the server is being rebooted or has crashed.
  
  Reconnection can be configured with retry-interval, exponential backoff, max retries.
  
  
• Automatic duplicate message detection
  
  Duplicate sent messages can be detected and rejected. This allows clients to safely resend the same data in case of failure without running the risk of duplicate messages in queues.
  
  
• 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.
  
  Clusters can be symmetric (i.e. each node connects to every other node) or in more complex topologies (e.g. chain of three servers - with all producers on first node and all consumers on third node and mediating through second node).
  
  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 message redistribution
  
  Messages can be automatically redistributed to other nodes with consumers to prevent stranding of messages on a node if all its matching consumers are closed.
  
  
• Client side load balancing
  
  Messages sent from a client, can be load balanced across the cluster with a configurable policy. round robin, first element, or random - or plug in your own policy.
  
  
• Flexible cluster topologies
  
  Form clusters with servers in a chain, in a symmetric cluster etc.
  
  
• Automatic, fast, client failover
  
  Clients can be configured to automatically failover and reconnect to a backup server in case of failure of the live server.
  
  This is done while preserving all transactional once and only once delivery guarantees, eliminating the possibility of lost or duplicated messages.
  
  
• Replication of data store
  
  The data store of a live server can be configured to be replicated to a backup server, so in event of failure of the live server, the data is available immediately for the backup server to use.
  
  
• Failover via shared file system
  
  If shared file storage is available (e.g. using a SAN), then a backup server can be configured to load the live servers journal from the SAN in case of failure of backup server, thus making its data available to the backup server.
  
  
• JMS bridge
  
  This allows you to bridge between any JMS 1.1 compliant provider and any other JMS 1.1 compliant provider.
  
  Bridges are configurable with selector, batch size etc.
  
  
• 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.
  
  
• Support for multi-language clients
  
  HornetQ can be accessed by clients in many different languages by using Stomp Connect
  
  Later releases of HornetQ will allow provide native STOMP, AMQP and REST support allowing access natively by clients written in many different languages.

• 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!

Features in 2.1

• Native STOMP support. HornetQ now supports STOMP natively - STOMP is a simple text oriented messaging protocol. STOMP clients are available in many languages.

• Web sockets support. HornetQ now supports HTML 5 web sockets. This means in browser Java script can now communicate directly with a HornetQ server. Applications of this would be in-browser trading applications, news feeds or stock tickers applications. This leverages JBoss Netty meaning it can scale to many thousands of concurrent connections.

• HornetQ now provides the built in JMS functionality in JBoss Application Server 6, M3 and later

• REST support. HornetQ now provides a REST interface thanks to Bill Burke.