changes-in-40.html - activemq-web - Git at Google

 <div class="wiki-content maincontent"><h3 id="Changesin4.0-NewFeaturesin4.0">New Features in 4.0</h3>

 <ul><li><a shape="rect" href="masterslave.html">MasterSlave</a> 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 <a shape="rect" href="exclusive-consumer.html">Exclusive Consumer</a> feature allows you to pin message processing to a single consumer in a cluser of consumers.</li><li>A new <a shape="rect" href="message-groups.html">Message Groups</a> 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 <a shape="rect" href="total-ordering.html">Total Ordering</a> feature to allow all consumers on a topic to see messages in the same order.</li><li>New <a shape="rect" href="how-can-i-monitor-activemq.html">JMX Management</a> and monitoring capabilities. You can now see statistics for each broker, destination, connector and connection!</li><li>Improved <a shape="rect" href="security.html">Security</a> 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 <a shape="rect" href="openwire-c-client.html">OpenWire C Client</a> 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 <a shape="rect" href="https://cwiki.apache.org/confluence/display/NMS">OpenWire dotNet</a> 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 <a shape="rect" href="consumer-priority.html">Consumer Priority</a> 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 <a shape="rect" href="consumer-dispatch-async.html">Consumer Dispatch Async</a> flag which allows you to configure how messages are sent by the broker to a consumer.  This controls if the broker uses <a shape="rect" href="seda.html">SEDA</a> or <a shape="rect" class="unresolved" href="#">STP</a> style dispaching.</li><li>A new plug-able topic <a shape="rect" href="subscription-recovery-policy.html">Subscription Recovery Policy</a> which allows you to configure how many transient messages are replayed when a <a shape="rect" href="retroactive-consumer.html">Retroactive Consumer</a> is created.</li><li>A new <a shape="rect" href="retroactive-consumer.html">Retroactive Consumer</a> 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><a shape="rect" href="per-destination-policies.html">Per Destination Policies</a> allow you configure the behavior of destinations.</li><li>The broker now supports per destination plugable <a shape="rect" href="dispatch-policies.html">Dispatch Policies</a> 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><a shape="rect" href="the-jms-connector.html">The JMS Connector</a> is used to establish connection to external JMS providers so that messages can be bridged between the system.</li><li><a shape="rect" href="the-proxy-connector.html">The Proxy Connector</a>. Is used to proxy connections to another broker.</li></ul>
 	</li><li><a shape="rect" href="slow-consumer-handling.html">Slow Consumer Handling</a> 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 <a shape="rect" href="destination-options.html">Destination Options</a> that allow you to do extend configuration of consumers.</li><li>Conumsers now use <a shape="rect" href="optimized-acknowledgement.html">Optimized Acknowledgement</a> by default to which results in increased performance.</li></ul>


 <h3 id="Changesin4.0-API/Configurationchanages">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 <a shape="rect" href="xml-configuration.html">Xml Configuration</a> 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
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 failover:tcp://host1:port1,tcp://host2:port2
 </pre>
 </div></div></li><li>The configuration options of transports have changed. See <a shape="rect" href="activemq-connection-uris.html">ActiveMQ Connection URIs</a> for a detailed guide of of all the options.</li><li>The spring package has gone; we now use <a shape="rect" class="external-link" href="http://xbean.org" rel="nofollow">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 <a shape="rect" href="configuring-brokers.html">Configuring Brokers</a> 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><a shape="rect" href="message-redelivery-and-dlq-handling.html">Message Redelivery and DLQ Handling</a> has been re-implemnted. Currently all messages sent poison messages are sent to a single DQL.</li><li>The <a shape="rect" href="jms-streams.html">JMS Streams</a> API has changed.</li></ul>


 <h3 id="Changesin4.0-GeneralChanges">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 <a shape="rect" href="openwire.html">OpenWire</a> 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 <a shape="rect" href="consumer-priority.html">Consumer Priority</a> 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 <a shape="rect" href="jms-streams.html">JMS Streams</a>.</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>
	<div class="wiki-content maincontent"><h3 id="Changesin4.0-NewFeaturesin4.0">New Features in 4.0</h3>

	<ul><li><a shape="rect" href="masterslave.html">MasterSlave</a> 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 <a shape="rect" href="exclusive-consumer.html">Exclusive Consumer</a> feature allows you to pin message processing to a single consumer in a cluser of consumers.</li><li>A new <a shape="rect" href="message-groups.html">Message Groups</a> 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 <a shape="rect" href="total-ordering.html">Total Ordering</a> feature to allow all consumers on a topic to see messages in the same order.</li><li>New <a shape="rect" href="how-can-i-monitor-activemq.html">JMX Management</a> and monitoring capabilities. You can now see statistics for each broker, destination, connector and connection!</li><li>Improved <a shape="rect" href="security.html">Security</a> 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 <a shape="rect" href="openwire-c-client.html">OpenWire C Client</a> 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 <a shape="rect" href="https://cwiki.apache.org/confluence/display/NMS">OpenWire dotNet</a> 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 <a shape="rect" href="consumer-priority.html">Consumer Priority</a> 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 <a shape="rect" href="consumer-dispatch-async.html">Consumer Dispatch Async</a> flag which allows you to configure how messages are sent by the broker to a consumer. This controls if the broker uses <a shape="rect" href="seda.html">SEDA</a> or <a shape="rect" class="unresolved" href="#">STP</a> style dispaching.</li><li>A new plug-able topic <a shape="rect" href="subscription-recovery-policy.html">Subscription Recovery Policy</a> which allows you to configure how many transient messages are replayed when a <a shape="rect" href="retroactive-consumer.html">Retroactive Consumer</a> is created.</li><li>A new <a shape="rect" href="retroactive-consumer.html">Retroactive Consumer</a> 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><a shape="rect" href="per-destination-policies.html">Per Destination Policies</a> allow you configure the behavior of destinations.</li><li>The broker now supports per destination plugable <a shape="rect" href="dispatch-policies.html">Dispatch Policies</a> 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><a shape="rect" href="the-jms-connector.html">The JMS Connector</a> is used to establish connection to external JMS providers so that messages can be bridged between the system.</li><li><a shape="rect" href="the-proxy-connector.html">The Proxy Connector</a>. Is used to proxy connections to another broker.</li></ul>
	</li><li><a shape="rect" href="slow-consumer-handling.html">Slow Consumer Handling</a> 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 <a shape="rect" href="destination-options.html">Destination Options</a> that allow you to do extend configuration of consumers.</li><li>Conumsers now use <a shape="rect" href="optimized-acknowledgement.html">Optimized Acknowledgement</a> by default to which results in increased performance.</li></ul>



	<h3 id="Changesin4.0-API/Configurationchanages">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 <a shape="rect" href="xml-configuration.html">Xml Configuration</a> 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
	<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
	<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
	failover:tcp://host1:port1,tcp://host2:port2
	</pre>
	</div></div></li><li>The configuration options of transports have changed. See <a shape="rect" href="activemq-connection-uris.html">ActiveMQ Connection URIs</a> for a detailed guide of of all the options.</li><li>The spring package has gone; we now use <a shape="rect" class="external-link" href="http://xbean.org" rel="nofollow">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 <a shape="rect" href="configuring-brokers.html">Configuring Brokers</a> 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><a shape="rect" href="message-redelivery-and-dlq-handling.html">Message Redelivery and DLQ Handling</a> has been re-implemnted. Currently all messages sent poison messages are sent to a single DQL.</li><li>The <a shape="rect" href="jms-streams.html">JMS Streams</a> API has changed.</li></ul>


	<h3 id="Changesin4.0-GeneralChanges">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 <a shape="rect" href="openwire.html">OpenWire</a> 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 <a shape="rect" href="consumer-priority.html">Consumer Priority</a> 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 <a shape="rect" href="jms-streams.html">JMS Streams</a>.</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>