<div class="wiki-content maincontent"><h3>New Features in 4.0</h3>

<ul><li><link><page ri:content-title="MasterSlave"></page></link> 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).</li><li>A new <link><page ri:content-title="Exclusive Consumer"></page></link> feature allows you to pin message processing to a single consumer in a cluser of consumers.</li><li>A new <link><page ri:content-title="Message Groups"></page></link> feaure allows you load balance messages accross a set of consumers but also garantee the message order for messages within a message group.</li><li>A new <link><page ri:content-title="Total Ordering"></page></link> feature to allow all consumers on a topic to see messages in the same order.</li><li>New <link><page ri:content-title="How can I monitor ActiveMQ"></page><link-body>JMX Management</link-body></link> and monitoring capabilities. You can now see statistics for each broker, destination, connector and connection!</li><li>Improved <link><page ri:content-title="Security"></page></link> plugin which provides JAAS support for authentication along with a pluggable strategy for authorization together with a default XML based implementation.</li><li>A new <link><page ri:content-title="OpenWire C Client"></page></link> 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.</li><li>An experimental <link><space ri:space-key="NMS"></space><link-body>OpenWire dotNet</link-body></link> is available, written in pure C# along with a JMS-like API for working on the .Net platform with ActiveMQ</li><li>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.</li><li>A new <link><page ri:content-title="Consumer Priority"></page></link> 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.</li><li>A configurable per <link><page ri:content-title="Consumer Dispatch Async"></page></link> flag which allows you to configure how messages are sent by the broker to a consumer.  This controls if the broker uses <link><page ri:content-title="SEDA"></page></link> or <link><page ri:content-title="STP"></page></link> style dispaching.</li><li>A new plug-able topic <link><page ri:content-title="Subscription Recovery Policy"></page></link> which allows you to configure how many transient messages are replayed when a <link><page ri:content-title="Retroactive Consumer"></page></link> is created.</li><li>A new <link><page ri:content-title="Retroactive Consumer"></page></link> 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.</li><li><link><page ri:content-title="Per Destination Policies"></page></link> allow you configure the behavior of destinations.</li><li>The broker now supports per destination plugable <link><page ri:content-title="Dispatch Policies"></page></link> so that you can choose the distribution algorithm used to send messages to a consumer.</li><li>The broker now supports two new types of connectors:
	<ul><li><link><page ri:content-title="The JMS Connector"></page></link> is used to establish connection to external JMS providers so that messages can be bridged between the system.</li><li><link><page ri:content-title="The Proxy Connector"></page></link>. Is used to proxy connections to another broker.</li></ul>
	</li><li><link><page ri:content-title="Slow Consumer Handling"></page></link> allows you to discard old messages for slow consumers on non-durable topics to avoid slowing down fast consumers</li><li>You can now specify <link><page ri:content-title="Destination Options"></page></link> that allow you to do extend configuration of consumers.</li><li>Conumsers now use <link><page ri:content-title="Optimized Acknowledgement"></page></link> by default to which results in increased performance.</li></ul>


<h3>API/Configuration chanages</h3>

<ul><li>as part of the move to Apache, the package name is now <strong>org.apache.activemq</strong> and not <strong>org.activemq</strong>.</li><li>the <link><page ri:content-title="Xml Configuration"></page></link> has changed a little; mostly its now in the ActiveMQ namespace and has a generated XSD and documentation.</li><li>the <em>reliable</em> transport has been renamed to <em>failover</em> 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
<structured-macro ac:macro-id="67446eff-165c-41df-a0ae-fbb115d9644a" ac:name="code" ac:schema-version="1"><plain-text-body>
failover:tcp://host1:port1,tcp://host2:port2
</plain-text-body></structured-macro></li><li>The configuration options of transports have changed. See <link><page ri:content-title="ActiveMQ Connection URIs"></page></link> for a detailed guide of of all the options.</li><li>The spring package has gone; we now use <a shape="rect" href="http://xbean.org">XBean</a> 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 <link><page ri:content-title="Configuring Brokers"></page></link> for more information on the new XML syntax.</li><li>ActiveMQTopic and ActiveMQQueue are now in the org.activemq.command package.</li><li>If you were creating a broker in Java code, the BrokerContainer has been replaced with BrokerService which is easier to use now.</li><li>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.</li><li><link><page ri:content-title="Message Redelivery and DLQ Handling"></page></link> has been re-implemnted. Currently all messages sent poison messages are sent to a single DQL.</li><li>The <link><page ri:content-title="JMS Streams"></page></link> API has changed.</li></ul>


<h3>General Changes</h3>

<ul><li>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.</li><li>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.</li><li>we no longer have hand-crafted marshalling code any more; its all based on <link><page ri:content-title="OpenWire"></page></link> and autogenerated from the open wire commands in the org.activemq.command package</li><li>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.</li><li>Two types of network bridges are now supported:
	<ul><li>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.</li><li>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.</li></ul>
	</li><li>The demand based forwarding bridge now take advantage of the <link><page ri:content-title="Consumer Priority"></page></link> to avoid forwarding messages to a remote broker if there is a local consumer consuming it's messages.</li><li>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 <link><page ri:content-title="JMS Streams"></page></link>.</li><li>JMS clients marshall fewer messages on the wire on for a rollback.</li><li>JMS clients marshall fewer messages when sessions/consumers/producers are closed.</li><li>The client and the broker make more extensive use of Thread Pools to avoid allocating idle threads that are not being used.</li></ul>
</div>