Trigger Control 1

[dotsavvy]

I have configured my MQ to start up a program when message is received.

How can pass the MsgId of the newly arrived message to the activated program so that it will process the message and then terminate ?

In this way, I can start multiple instance of the same program where each will process only a message.

If the above is possible, how can control the number of instance of the activated program at one time to control the load on the server.

Thanks in advance

 

[pmeekin]

Can't think of an easy way to do this off the top of my head. You have to remember that MQ Triggering is a relatively simplistic mechanism. Basically, all you can do is start a program when your particular triggering conditions are satisfied. I guess the MQ designers didn't feel that it was necessary to identify WHICH message caused the trigger event and I have some sympathy with this view. Note that there are a lot of characteristics of triggering that would make this requirement meaningless in most situations anyway.

For multiple processes you have two choices. You could start each triggered application as a background task so that the trigger monitor returns immediately and can service more incoming trigger messages by launching more instances of your app in parallel. Unfortunately you cannot control how many of these will run concurrently.

Alternatively, you would need to write a more sophisticated app that would perhaps start up a 'thread pool' of worker processes to process your incoming messages. Note that I'm suggesting that you only trigger the controlling app which would then start the individual instances itself as messages continue to appear on the incoming queue.

Hope this helps,
Paul

 

[smeridew]

It sounds like your application is a candidate for the trigger "EVERY" setting. Essentially, this means that the queue manager will create trigger mesages for every message that arrives on the input queue. Your trigger monitor will then launch an instance of your app for every message that arrives.

In my opinion, this is a bad design choice. It is almost always preferential to have your application process as many messages from the input queue as possible before teminating.

We have created an application configuration similar to what Paul described in the previous reply. Our input queue is set to trigger FIRST, and the application ID is "C:\app\multiple.exe receiver.exe 3". Multiple.exe is a launcher program that reads the program name to be launched as its first argument, and the number of instances to launch as the second argument. In our case, we will launch 3 instances of receiver.exe when the input queue goes from 0->1 messages. The receiver.exe programs issue a get with wait for a pre-determined number of milliseconds before terminating.

Cheers,

Scott Meridew
MQ Squared Inc.

http://www.mqsquared.com

 

[dotsavvy]

I am trying to do parallel processing of the incoming messages but wants to have the flexibility of controlling the no of parallel processing of these nessages.

I am thinking of having a Single Dispatcher (which can be a daemon or activated by trigger) which will read the MsgId of incoming message and spawn the correct program to service the message by passing the MsgId to the spawned program.

Can the dispatcher read the MsgId and Header without reading the message and let the spawned program read the message and process it ?

Is this feasible ?

Thanks in advance.

 

[pmeekin]

You have to be careful about confusing trigger messages with application messages. When a message is placed onto your (triggered) application queue, a trigger message is generated and placed onto the Initiation queue associated with that application queue. The trigger monitor (yours or IBM's) is listening for trigger messages. When one arrives, it starts the relevant program and passes the trigger message as a parameter to the started program. The trigger message contains the name of the application queue that caused the trigger message but contains no information about the specific message that caused it.

But is this a problem? If I understand your requirements all you need to do is have a single app (either triggered or not) which browses any incoming application message and then launches the correct program for that message type. You could pass the msgid as a parameter to the second app so that it would know which message to retrieve.

Hope this helps,
Paul

 

[dotsavvy]

You are right. I would like to know if this can be done i.e. the single app able to determine the msgid and pass it to the launched second app.

Is this common MQ programming and is there any sample code for this available ?

Thanks

 

[pmeekin]

There is no reason why this can't be done. It's more a case of deciding whether this is the best method but only you can answer that.

Questions:
How frequently do you expect messages to appear on your application queue?
How long does it take to process each message?
How much parallel processing of messages do you need (i.e. parallel threads)?
How many different message types do you expect (requiring different apps to be launched)?

Based upon the answers to questions such as these you can decide whether to write a single 'App Launcher' program (possibly triggered by MQ) which starts up the relevant application depending upon which types of messages it browses on the app queue or to write one or more message processing applications which wil run independently, waiting for messages to appear.

Another alternative might be to send different types of messages to different queues with a particular message processing app dedicated to each.

The beauty (?!) of MQSeries is that there is rarely fewer than a handful of ways of solving a particular problem. Your mission, should you decide to accept it ... ;-)

I'm not aware of sample code but it is pretty straightforward. Check out the MQ samples if you're not familiar with the MQI.

Cheers,
Paul