From activemq-commits-return-494-apmail-geronimo-activemq-commits-archive=geronimo.apache.org@geronimo.apache.org Thu Feb 02 16:36:28 2006 Return-Path: Delivered-To: apmail-geronimo-activemq-commits-archive@www.apache.org Received: (qmail 45931 invoked from network); 2 Feb 2006 16:36:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Feb 2006 16:36:25 -0000 Received: (qmail 77777 invoked by uid 500); 2 Feb 2006 16:35:50 -0000 Delivered-To: apmail-geronimo-activemq-commits-archive@geronimo.apache.org Received: (qmail 77750 invoked by uid 500); 2 Feb 2006 16:35:50 -0000 Mailing-List: contact activemq-commits-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-dev@geronimo.apache.org Delivered-To: mailing list activemq-commits@geronimo.apache.org Received: (qmail 77741 invoked by uid 99); 2 Feb 2006 16:35:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2006 08:35:50 -0800 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Feb 2006 08:35:37 -0800 Received: (qmail 44320 invoked by uid 65534); 2 Feb 2006 16:35:13 -0000 Message-ID: <20060202163513.44319.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r374430 [8/45] - /incubator/activemq/site/ Date: Thu, 02 Feb 2006 16:33:52 -0000 To: activemq-commits@geronimo.apache.org From: jstrachan@apache.org X-Mailer: svnmailer-1.0.5 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Added: incubator/activemq/site/Changes+in+4.0 URL: http://svn.apache.org/viewcvs/incubator/activemq/site/Changes%2Bin%2B4.0?rev=374430&view=auto ============================================================================== --- incubator/activemq/site/Changes+in+4.0 (added) +++ incubator/activemq/site/Changes+in+4.0 Thu Feb 2 08:31:10 2006 @@ -0,0 +1,275 @@ + + + + + + + + ActiveMQ - Changes in 4.0 + + + + + + + + + + + + + + + +
+ + + + + + +
+

Overview

+ +

Community

+ +

Using ActiveMQ

+ +

Features

+ +

Connectivitiy

+ +

Utilities

+ +

External Tools

+ +

Related Projects

+ +

Support

+ +

Developers

+ +

Tools we use

+ +

Feeds

+ + + + + + + + + +
+
+
+ Site +
+ + + News +
+
+ +
+ + + + + +
+ Changes in 4.0 + + +
+
+ + +
+
+

New Features

+
    +
  • 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!
  • +
  • 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 new plug-able topic Subscription Recovery Policy which allows you to configure how many transient messages are replayed when a Retroactive Consumer is created.
  • +
  • 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.
  • +
  • Per Destination Policies are now supported and configured using the Destination Options Syntax.
  • +
  • The broker now supports per destination plugable Dispatch Policies so that you can choose the distribution algorithm used to send messages to a consumer.
  • +
  • The broker now supports two new types of connectors:
      +
    • The JMS Connector is used to establish connection to external JMS providers so that messages can be bridged between the system.
    • +
    • The Proxy Connector. Is used to proxy connections to another broker.
    • +
    +
  • +
+

API/Configuration chanages

+
    +
  • 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
    +
    failover:tcp://host1:port1,tcp://host2:port2
    +
    +
  • +
  • The configuration options of transports have changed. See ActiveMQ 4 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.
  • +
  • Message Redelivery and DLQ Handling has been re-implemnted. Currently all messages sent poison messages are sent to a single DQL.
  • +
  • The JMS Streams API has changed.
  • +
+

General Changes

+
    +
  • 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.
  • +
+
+
+ +   +