MQ Message Replication (MQMR) is an MQ API Exit. An MQ API Exit is configured to run within the queue manager’s address space (or the application’s address space if the application connects in bindings mode to the queue manager).
I designed MQMR to be extremely light-weight when replicating messages to target queues. MQMR determines if a queue will have its messages replicated when an application issues an MQOPEN API call. If MQMR determines that the queue name is a match then MQMR hooks into the MQPUT and MQCLOSE API calls, otherwise, everything related to the opened queue is ignored.
My thinking was that the MQAdmin and/or application teams would determine which queues would need to be replicated, the MQMR IniFile would be updated and during the next maintenance window for either the application or queue manager, the changes would be picked up when the application issues the MQOPEN API call after a reconnection.
A couple of weeks ago, a customer said they were making changes MQMR IniFile they were using and the new source queues were not causing MQMR to replicate the messages. I asked if the application(s) were connected to the queue manager (and stayed connected) before (and after) the updates were made to the MQMR IniFile. They said yes. So, I explained that the application needed to be recycled (or the queue manager). They explained that they were constantly making changes to the MQMR IniFile adding/updating/removing source queues. They requested that I make MQMR more dynamic, be able to accept and immediately implement new changes without requiring recycling of either the applications and/or queue manager.
My biggest concern with a more dynamic approach for MQMR is the memory usage. I already have customers using Capitalware products (i.e. MQMR, MQ Auditor, etc.) with queue managers installed and configured in VMs with extremely low memory allocations.
One application may open 1 or 2 queues, no big deal. The issue is that MQMR is an API Exit, so ALL of the applications connecting to a queue manager, opening queues will need to be tracked. There can easily be hundreds (or thousands) of applications connecting to a queue manager, each opening 1 or more queues. Now we are talking about a massive amount of memory being allocated and used by MQMR to track opened queues.
I reviewed the code and went crazy with a fine tooth-comb determining what was the absolute minimum memory MQMR would need to track an opened queue. I got the structure down to 70 bytes (62 bytes for 32-bit) and most of that is the queue name (48 bytes).
So, I have rewritten the internals of MQMR to be truly dynamic when it comes to an MQAdmin making changes to the MQMR IniFile. Any changes to the MQMR InFile will be immediately reflected in ALL instances of MQMR.
There are 2 small disadvantages to this new dynamic MQMR modification:
(1) MQMR will use more memory. Now, I have done my best to absolutely minimize the amount of memory used for each opened queue but MQMR will still use more memory than before.
(2) MQMR will be invoked for MQPUT and MQCLOSE API calls for all applications regardless if a source queue is being replicated or not. I added code at the very beginning of the routine for the MQPUT invocation to check if the source queue if being replicated, otherwise exit immediately.
I have completed a wide variety of tests and everything looks good. The customer is now also testing the latest release of MQMR.
If anyone would like to test out the latest release then send the email to support@capitalware.com
Regards,
Roger Lacroix
Capitalware Inc.
