MasterSlave provides support for continuous availability and fault tolerance of brokers to be able to handle catastrophic hardware failure and not loose a message (or get duplicates).
A new Exclusive Consumer feature allows you to pin message processing to a single consumer in a cluser of consumers.
A new Message Groups feaure allows you load balance messages accross a set of consumers but also garantee the message order for messages within a message group.
A new Total Ordering feature to allow all consumers on a topic to see messages in the same order.
New JMX Management and monitoring capabilities. You can now see statistics for each broker, destination, connector and connection!
Improved Security plugin which provides JAAS support for authentication along with a pluggable strategy for authorization together with a default XML based implementation.
A new OpenWire C Client is now available. This client talks the same wire protocol that the standard java client uses so every messaging broker feature available to the java client is available to the c client.
An experimental OpenWire dotNet is available, written in pure C# along with a JMS-like API for working on the .Net platform with ActiveMQ
Queues can now be loaded up with persistent messages without locking up the broker. Persistent messages are now swapped out of memory when no consumer needs it soon.
A new Consumer Priority feature allows you to build location affinity by assignin a priority to consumers. The broker can then dispatch messages to higher priority consumers before dispatching to lower priority consumers.
A configurable per Consumer Dispatch Async flag which allows you to configure how messages are sent by the broker to a consumer. This controls if the broker uses SEDA or STP style dispaching.
A new Retroactive Consumer feature allows topic consumers to "go back in time" so that it receives old messages when the subscription is activated. If the consumer is a durable consumer, he recover all the messages that are still in the persistent store.
as part of the move to Apache, the package name is now org.apache.activemq and not org.activemq.
the Xml Configuration has changed a little; mostly its now in the ActiveMQ namespace and has a generated XSD and documentation.
the reliable transport has been renamed to failover to make it more clear what it does; we're working on a separate DR mechanism to provide data centre resilliance. So if you wish to connect to one of a number of URIs try
The configuration options of transports have changed. See ActiveMQ Connection URIs for a detailed guide of of all the options.
The spring package has gone; we now use XBean to configure ActiveMQ. See the org.activemq.xbean.BrokerFactoryBean if you want a factory bean to use in regular spring instead of the org.activemq.spring.BrokerFactoryBean. See Configuring Brokers for more information on the new XML syntax.
ActiveMQTopic and ActiveMQQueue are now in the org.activemq.command package.
If you were creating a broker in Java code, the BrokerContainer has been replaced with BrokerService which is easier to use now.
The connection URL options have changed slightly to provided more persise configuration options of the transport and wireformat and to allow validation of the options.
The JDBC persistence adapter now uses JDBC statement batching to increase it's performance with the database. This should reduce the amount of time a checkpoint takes.
QueueBrowsers now play nicely with a queue that is currently being consumed from. It gives you a true snapshot of what the queue looked like when you created the browser and it does not affect the dispatching of messages to active consumers.
we no longer have hand-crafted marshalling code any more; its all based on OpenWire and autogenerated from the open wire commands in the org.activemq.command package
The network bridges used for broker to broker messaging now use a lower level ActiveMQ command and transport API instead of the JMS API, this allows them to use more optimizations and have a lower per bridge resource consumption while letting the JMS client API implementation reduce it's complexity.
Two types of network bridges are now supported:
A simple forwardng bridge - sends all messages as soon as possible to the remote broker. Great you know the usage patterns up front and allways want to do store and forward to a central broker.
A demand based forwarding bridge (same type of bridge that was using in ActiveMQ 3.x) which detects consumer demand on the remote broker and only forwards messages as needed.
The demand based forwarding bridge now take advantage of the Consumer Priority to avoid forwarding messages to a remote broker if there is a local consumer consuming it's messages.
Message fragmentation is no longer done. Fragmented messages add yet another level of complexity when you introduce broker networks. Large objects/streams should be transfered using the JMS Streams.
JMS clients marshall fewer messages on the wire on for a rollback.
JMS clients marshall fewer messages when sessions/consumers/producers are closed.
The client and the broker make more extensive use of Thread Pools to avoid allocating idle threads that are not being used.