Mule ESB 3.2.0 Release Notes
The Mule team is proud to announce the release of Mule 3.2 Enterprise, the most stable and reliable version of Mule with radically more powerful capabilities for reliability and visibility
Feature Highlights:
-
Request-Reply messaging style for Flows
-
Tighter control over Flows
-
Improvements in transactional behavior
-
Better performance through SEDA queues
-
Drools support added
-
Fine-grained class loading control and plugin packaging
-
New "Retry Until Successful" message processor
-
Simplified data-source configuration for JDBC transport
-
High Availability Clustering (EE) Enterprise Edition
-
Business Event Analyzer (EE) Enterprise Edition
-
More REST APIs for Management (EE) Enterprise Edition
Important notes for this release
-
The default rules for how a Mule flow is processed have been made more consistent, and configurations have been given the ability to override these defaults:
-
A Mule flow that is not transactional and whose inbound endpoint uses the one-way exchange pattern will, by default, use a SEDA queue and be processed asynchronously.
-
A Mule flow that is either transactional or whose inbound endpoint uses the request-response exchange pattern will, by default,be processed synchronously.
-
These defaults can be overridden with a new construct called a Processing Strategy. See Flow Processing Strategies for information on this.
-
Processing strategies also allow the details of threading to be configured. Thus, the threading-profile element is no longer supported on flows.
-
-
Request Reply messaging style has been added to flows. This messaging style is well suited for scenarios where you want to send a request that results in an asynchronous reply message.
Limitations
-
Currently a Mule HA Cluster supports up to 4 nodes per Cluster
-
Nodes within a mule cluster nodes are intended to run each on on a separate psychical/virtual machine.
-
Currently, the Until-Successful router, which will retry an operation until it succeeds, will retry it only on one node of a cluster.
Known Issues
-
Two of the schema references in the configuration file for the mmc application in the ESB Enterprise v3.2 trial download point to 3.1 locations. This can cause problems in starting the server. To fix the issue, open the configuration file (<mule>/apps/mmc/mule-config.xml) and
make the following updates: -
When using the Mule ESB Enterprise management console in the EE bundle the mule instance cannot be used as a cluster node. When managing clusters it is recommended that the management console be installed in a web container such as Apache Tomcat.
-
Currently if two nodes of a four nodes cluster go down simultaneously, there can be a possibility of losing messages. This will be addressed in a future release.
-
Due to a bug in ActiveMQ, when requesting for an event more than one time from a transactional endpoint within the same transaction, the second request will return always null, or hang if no timeout is used.
Migration
For further information on migrating from Mule 3.1.x to 3.2 see the migration topic.
Bug Fixes in this release:
JIRA Issues (131 issues)