MQSeries.net :: View topic - Triggering 'EVERY'

exerk · Posted: Mon Oct 06, 2014 3:25 am Post subject:

OK, I'm throwing this one out to the floor as a head-check, i.e. whether I'm seeing what I'm seeing, or misinterpreting what I'm seeing, or there is a bug and I need to open a PMR...

-----------------------------------------------------------

BACKGROUND
V7.5.0.2/4 (see later) on Linux (RHEL5): A roll-your-own 'monitoring' solution is using the MA01 SupportPac to put 'event' messages which are centralised to a triggered queue, which is set to FIRST with the queue manager's TRIGINT set to all the nines (999,999,999). The trigger fires a shell script which calls a Perl script, which again uses the SupportPac to read off the messages, which are dumped to a flat file, but this has also been tested by calling the Perl script directly.

So far testing has been carried out with a low volume of messages (sub-100).

FUNCTION
The 'monitoring' application, on first starting up, does the following:

1. Inquires on the queue depth;
2. Gets the MQMD detail of each message and logs it to a temp file;
3. Browses the messages and writes the content to flat file;
4. Deletes the messages with reference to the previously logged MQMD details in the temp file;
5. Ends and awaits the next trigger.

As far as I am aware there is no Unit-of-Work or sync-pointing going on; and I'm only the messenger - I have already given the standard lecture in regard to efficient MQ application design and triggered applications.

ISSUE
The logging of the 'monitoring' application appears to indicate that trigger EVERY is occurring, i.e. the first log messages gives the queue depth but subsequent log messages state that the queue is empty, which is consistent with the first 'instance' removing the messages and subsequent 'instances' finding the queue empty, so the observed behaviour is that an EVERY condition is being encountered.

Obvious concerns are that when this gets ramped up to real volumes that the box hosting the queue manager is going to be run out of resources and shuffle off its mortal coil...

PROBLEM DETERMINATION
1. I ran the Trigger Monitor in the foreground to double-check what I was seeing, and before I set the trigger ON on the queue I saw the standard 'Waiting for a trigger message' print; once triggering was set ON I saw the first trigger message print on screen ('number of messages on queue...' - 'monitoring' application originated message fed back in the trigger message output) with the 'End of application trigger' print, and would have expected to see another 'Waiting for a trigger message' print and nothing else until a new set of messages arrived, however, that's not the case - the 'Waiting for a trigger message' was printed again but immediately followed by a 'Queue empty...' ('monitoring' application originated fed back in the trigger message output) message, and so on, the number of entries matching the number of messages originally on the queue;

3. I did do a trace on the Trigger Monitor (pre-FixPack application) but could see nothing obvious within it;

4. Service was applied (FixPack 4) and everything re-tested again - same result;

5. Incomplete at present - test on another piece of infrastructure and MQ version to determine whether this is application related (UoW etc.) or a bug in the platform/version build.

INITIAL CONCLUSION(S)
The only thing that presently springs to mind is that TRIGINT is not being honoured.

-----------------------------------------------------------

Any general ideas/PD ideas gratefully accepted.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.