MSMQ Connector Release Notes - Mule 3

Fixed: Threads performing MSMQ receive() got stuck in SocketInputStream.socketRead() and it required an application restart to recover from the issue.

Improved: Contract updates through requests/responses with the Gateway.

Fixed: Impersonation issues when building the security context.

Added: Support new message delivery working mode (two modes available now: no-acknowledgement & at-least-once).

Improved: Error messages for invalid credentials and related things.

Improved: Connection retry on some scenarios when Gateway is not available.

Improved: Memory usage & resources disposal.

Fixed: Test connection when there is an error loading user profile.

Added: New property mule-msmq-queue-override-authenticate to allow connection to authenticated queues.

Added: New property mule-msmq-queue-override-transactional to allow send to remote queues marked transactional.

Improved: Resilience to high CPU and low memory conditions.

Improved: Resilience in the event of errors while dequeuing messages from MSMQ.

Fixed: Recovery from a processing stall when MSMQ service was unavailable.

Fixed: Connection pool cleanup to prevent leak due to internal Jersey exceptions under stress conditions.

Fixed issue with HTTP connections not closed properly after being used.

Added connection pool for reusing existing HTTP connections.

Added new "cleanup-delay" setting for avoiding concurrency issues in load balanced scenarios.

Fixed an issue where public MSMQ queues in Active Directory could not be read.

Added support for running the Windows Gateway Services in a load balanced configuration to allow for fault tolerance.

See Windows Gateway Services Guide for the latest installation software.

Upgraded Jersey libs to 2.11 to prevent conflict with internal version used by Mule server.

Fixed an issue where the polling interval specified in the UI was not honored by the dequeuing service in the gateway.

Tweaked performance to provide consistent response time under heavy load.

If a queue name was not specified at the global element level, an error message would be reported repeatedly stating org.mule.modules.msmq.MsmqException: Queue not found:"null" even if the connector instance defined a queue name that overrode this global queue setting. The queue connectivity test is no longer run if the global element does not specify a queue name to use.

In Studio 5.0.2 and ESB 3.6, an error was reported with Test Connection stating that the test failed due to `java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig. `This was caused by a Jersey version in the connector being out of sync with Studio and ESB server.

If a Mule app was hot-redeployed in Studio or ESB Server, the MSMQ connector would report an error stating that ` Receiving Thread ERROR org.mule.modules.msmq.MsmqConnector - Error while trying to process response. Cannot process event as "applicationName" is stopped (org.mule.api.lifecycle.LifecycleException).` This was caused by the stop callback never being invoked.

Performance tuning: The performance of the connector has been improved for high transaction volumes where message payloads exceed 1kB.

Default port change: The default listener port of the Anypoint Gateway Service that provides MSMQ connectivity has been changed to 9333 to prevent conflict with Service Bus which runs on port 9000.

Message exception management: Errors occurring during the process of sending or receiving queued messages now always raise an exception directly in the flow. This allows the built-in logging and error routing support within Mule to leverage automatically. Where no exception management strategy is defined, messages are returned to the dead-letter-queue as specified in the instance config, or the system dead-letter-queue of the machine where the target queue lives.

Exactly-once in-order support: When the message-processing-strategy of a flow is set to synchronous, messages that are processed from MSMQ queues are guaranteed to be presented to the flow in exactly the order that they were sent, and to be received once and only once.

CloudHub support: The MSMQ connector now has to be certified for use on CloudHub. You can deploy your Mule application to CloudHub. Ensure that the connector configuration points to the Anypoint Gateway Windows Service running on-premises. The Anypoint Gateway Windows Service provides the interface into the MSMQ infrastructure in your enterprise, so it must be installed and verified as working prior to deploying.

Message timeouts: You can now set the number of seconds for the timeToBeReceived and timeToReachQueue property settings. When either of these timeouts occur, messages are moved to a dead-letter-queue that exists as a sub-queue of the origin. You can customize the location of the dead letter queue using the instance properties of the connector. Both properties default to zero (0), which indicates that the property never times out.

Message acknowledgement: Messages that are not normally MSMQ messages are now surfaced in the flow, allowing an alternative sub-flow to handle conditions such as correlation on ACK or retry on NACK. These messages can be identified by the message properties. You can set a Choice control flow shape using custom recovery or journaling logic.

Zero-message-loss to bus: When using transactional queues, the MSMQ connector now guarantees zero-message-loss while the message is delivered to the bus. Only after the message is successfully received by Mule can it be removed from the origin queue. Users don’t need to perform additional configuration other than selecting an MSMQ queue that is marked as transactional. Mule manages a reliable dequeue behind the scenes.