Mule MSMQ Connector helps in reading/writing messages from MSMQ. Personally I have had few hiccups in getting this working and even to extent of raising few defects on the connector and windows gateway service. Although personally (at the time of writing this blog), I am still not 100% confident on this connector working (as windows gateway service is a black box) but I am very much impressed the way it was designed and works. The basic details and configuration of this connector and gateway are very well laid out at Mule website but there are few things which I thought would be worth mentioning.
Windows Gateway Service is responsible for reading/writing messages in batches to MSMQ and exposes this functionality via API. Everytime message is read operation is done, messages are first placed in the subqueue inside MSMQ. This placing of messages in subqueue is termed failfirst where if for any reason there was an exception while processing the message by mule application, the message is not lost. There can be more than one MSMQ connector connected to the same windows gateway service or there can be multiple windows gateway services connecting to same MSMQ.
Messages are picked up in batch size and processed synchronously. While processing these messages, if there was any failure/exception thrown all the messages in the batch will end up back in the MSMQ. This can potentially lead to duplicate messages being processed. Technically you can configure the batch size as 1 which means only one message is picked up at a time and avoid duplicates but this will mean a performance hit. Also, you need to make sure the mule flow is configured with processing strategy as synchronous as this will make sure that the same thread is used by connector and to process the message. If you configure as asynchronous, there are two threads running and the main thread used by connector will not know about the exception while processing the message which is running on another thread thereby loosing the message incase it wasnt processed.
However, as of this date(1/2/4/2016) there is a bug with MSMQ connector and synchronous flow that – if you use Java component within the flow, any flow variables before the Java component are lost. Couple of work arounds for this is to either use java transformer instead of component or save values in the message properties instead of flow variable.
Cleaning up messages from subqueues:
As mentioned above when messages are picked up, they are put in a subqueue first. Messages from subqueues are cleared up if the messages picked up in the batch were all successfully processed. However, if there was any exception while processing any message, the messages remain in the subqueue. Windows gateway service configuration has a cleanup-delay which when expired, starts cleaning up all the subqueues for the connected queues. In case of multiple gateway services pointing to the same MSMQ server/queue, it is recommended to configure the value of cleanup-delay value as “0” on one server and “30” on the other server running the windows gateway services.
Windows Gateway Service Release Notes: https://docs.mulesoft.com/release-notes/windows-gateway-services-release-notes
Note: This post is related to Windows Gateway Service version 1.8.5.
