| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How does MQ handle mgs with mutiple consumer applications? |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqjeff |
 Posted: Thu Aug 21, 2008 5:26 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
But rxm8778 is not asking about TRIGGER TYPE EVERY.
rxm8778 is asking about how to trigger more than one application from a single trigger message - not asking how to generate more than one trigger message. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Aug 21, 2008 5:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The IBM-supplied trigger monitor application, as written, launches the application named in the PROCESS object.
Source code for the trigger monitor is supplied, so you could modify it to launch various applications.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 21, 2008 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Ok so we have 1 app posting one msg and 7 different apps needing to get that msg and process it, each of them....
Typicall for either a distribution list being used by the putting app or a PUB/SUB scenario. Have each subscriber be a durable subscriber and specify it's subscription queue. You can now put to 1 queue and get the msg on 7 different queues. Each app can be triggered or not.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 21, 2008 9:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Call me dense...
Is the requirement: 7 seperate instances of the application must process the same message?
And these instances are on workstations (meaning mq client pplications)?
And that each application instance needs to do this to update a db on the client platform?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| rxm8778 |
| Posted: Thu Aug 21, 2008 10:28 am Post subject: |
|
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
Bruce
For the sake of clarification, I will re-explain the requirements...
There is one application queue on to which messages arrive. Each message represent a set of intructions for the consumer application to execute. Once a message is read from the queue, executing the set of instructions contained in the message takes the consumer application 1-2 hours per message. The consumer application is unable to consume messages while it is processing the instructions. The consumer application runs on a workstation while the MQ server runs on a seperate machine. (The consumer app is not an MDB nor does it use message listener)
The business partner has mutiple other unused workstations (7 of them) which he would like to use to increase efficiency. He has installed the consumer application on each of these workstation then he consulted with me on how to set up MQ to allow these other consumer applications to be able to read messages from that same application queue. That way he can have 7 consumer applications working in parallel and increase efficiency.
I do understand  that the best approach here is to have each consumer application issue a get with wait call on that application queue and process messages as they arrived (with the understanding that the distribution between all 7 machine won't be even)
** When the BP asked me how would MQ prevent 1 message to be consumed by two different applications at the exact same time, I told him that MQ does not allow duplication of messages and unless he could prove otherwise, he should trust me (Many thanks to Peter for helping me formulate this answer) 
But thinking outside of the box a little bit,  I was wondering if there was a way to trigger these 7 applications from one queue using MQ triggering.
- for one it seems to me that this is simply impossible because the relationship between a triggered queue and the process definition is 1 to 1.
I hope this summary helps clear it out for you.
Last edited by rxm8778 on Thu Aug 21, 2008 10:34 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 21, 2008 10:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| You can reexamine what the application that is being triggered does. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 21, 2008 10:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
But thinking outside of the box a little bit, I was wondering if there was a way to trigger these 7 applications from one queue using MQ triggering.
- for one it seems to me that this is simply impossible because the relationship between a triggered queue and the process definition is 1 to 1. |
I think I've got it now. This isn't all that out of the box.
From your narrative, the 7 applications are running on workstations with the MQ client only. Yes?
For this discussion, please ignore triggering for a moment.
Let's say that the 7 applications are started by automation or part of boot. Each and every one of them can concurrently MQCONNect to the qmgr, MQOPEN the one and only one application queue, then MQGET with WAIT.
If one message arrives, the first (quickest) instance will get the message. (MQ will not allow another application instance to MQGET the message if another application has already done so.)
I'm guessing that the application will get the message in a Unit of Work and MQCMIT the message out of the application queue when the 1 to 2 hour process is complete for this message; or, alternatively, MQBACK the message back into the queue if the 1 to 2 hour processing fails and needs to be tried again. (If processing is done outside a UofW, then the consuming application MQGETs it's message immediately and destructively. This is a programming choice.)
When another message arrives, the next instance of the application (on another workstation) will do the exact same thing.
Given this scenario (and I hope I've understood the requirement), all 7 instances will continuously watch the application queue for messages. When the 8th message arrives AND all other instances of the application are busy consuming/processing their message, number 8 waits.
What additionally are you trying to accomplish with triggering? There are other methods of launching an instance of an application, like CRON for example.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| rxm8778 |
| Posted: Thu Aug 21, 2008 11:47 am Post subject: |
|
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
You definitely understood my requirement. From your explanation above, that is the behavior I envisioned with the get with wait approach.
| bruce2359 wrote: |
| What additionally are you trying to accomplish with triggering? There are other methods of launching an instance of an application, like CRON for example. |
Well from my original post, you can see that I was just looking at trigerring as an alternative approach to having the application issue a get with wait. I was just wondering if rather than having each application issue a get with wait, there was a way for MQ to be able to trigger these seven applications at the arrival of the message. Of course I am not talking about triggering all 7 applications at once...
The scenario I was thinking of was along the lines...
message 1 arrives and application 1 is triggered.....message 7 arrives application 7 is triggered. But when I got to think about what would happen if message 8 arrives???? That's when I got back to reality and realized that MQ is not smart enough to know that all the applications are busy (1-2hours doing the processing) do not trigger them.
As a matter of fact MQ just can't trigger 7 seperate applications from 1 application queue. The product just does not have  that functionality.
Early in this conversation thread I thought that Peter was saying that 1 application queue can trigger multiple applications.... But I think what he really meant was 1 initiation queue can receive trigger messages that trigger various different applications. In that case though you would need 1 application queue for each triggered process but in my case I only have and only one application queue (not 7 of them).
Great discussions though... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 21, 2008 12:49 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| That's when I got back to reality and realized that MQ is not smart enough to know that all the applications are busy (1-2hours doing the processing) do not trigger them. |
Your requirement that the triggered applications be MQ clients, and only one triggered instance per platform, and multiple platforms, wasn't in mind when the folks at the MQ factory developed triggering.
| Quote: |
| ...trigerring as an alternative approach to having the application issue a get with wait. |
There is substantial o/s overhead involved in launching an application for the first time.
MQGET without WAIT would result in a 2033 no messaage available, and the program would end itself. It would need to be re-launched for the next message, and the next.
Once the application is launched, overhead for MQGET with WAIT is trivial. If there is no message, WAIT 5 seconds would result in 2033 after 5 seconds; then the program would re-issue the GET/WAIT; then repeat nnnn times. If a message arrives before the 5 seconds, the WAIT is cancelled immediately.
For these reasons, MQGET with WAIT is the preferred coding technique.
Welcome back to reality. .
(EDIT):
| Quote: |
| Early in this conversation thread I thought that Peter was saying that 1 application queue can trigger multiple applications.... But I think what he really meant was 1 initiation queue can receive trigger messages that trigger various different applications |
A single application queue can only point to one initiation queue. Multiple application queues can use the same initiation queue. As distributed, the runmqtrm dutifully launches the application named in the PROCESS object. The PROCESS is named in the application queue object definition.
Which application gets triggered is up to the trigger monitor application (runmqtrm). Trigger type EVERY will cause the trigger to fire for each message that arrives; thus, multiple instances of the same program.
But, you can modify the runmqtrm source code to do pretty much what you want the trigger monitor application to do for you. There are data attributes in the application queue object and process object that get passed to the trigger message.
I'd suggest that you read the pages in the WMQ Application Programming Reference and WMQ Application Programming Guide for details on triggering, and especially why triggers go bad.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
