| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Triggering applications running on MQ Client |
« View previous topic :: View next topic » |
| Author |
Message
|
| jackie_viv |
 Posted: Tue Dec 02, 2003 2:31 am Post subject: Triggering applications running on MQ Client |
 |
|
Newbie
Joined: 02 Dec 2003
Posts: 2
Location: Bangalore-India
|
Hello All,
I am not sure whether this will work or not. But please give your suggestions on how I can implement this.
I have a MQ Server running in Z/OS region and a client in Win2K server.
I have some applications running on both Z/OS and W2K.
I have done the setup for client communication which will put and get the mesg from a queue.
Now, I want to trigger the applications that are running on client side, when there is a msg placed in the queue on server side. The client should pick the msg from the server side and give it for further processing.
IF the trigger is not possible, is there any other way, where I can inform the client side applicaiton to pick the msg placed in the queue for it. (ofcourse, using two qmgrs on both sides will solve the problem)
thanks in adv
viv |
|
| Back to top |
|
 |
| emiranda |
| Posted: Tue Dec 02, 2003 3:03 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
You can use the Client Trigger Monitor tool (runmqtrc) that is part of MQSeries package.
Usage:
runmqtmc [-m QMgrName] [-q InitQ]
Rgds,
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 02, 2003 5:06 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can run the client application all the time, using MQGET with WAIT and it will process the next available message as soon as it arrives on the queue, loop around and issue another MQGET with WAIT after processing the message.
A trigger monitor is just an indirect way of doing the same thing. For messages that arrive frequently it can be much less efficient. In this case your code should still loop around and keep processing messages until the queue is empty (NO_MSG_AVAILABLE) but then exit.
There is also a support pac that offers a client trigger monitor as an NT/Windows service. This is probably a better way to run it.
If you do run the command line version, do so from inside a small windows batch command file that re-issues the command (after a sleep of say 30 seconds) in a loop, because the command sometimes terminates and triggering stops (eg if the queue manager is stopped and re-started). |
|
| Back to top |
|
|
| emiranda |
| Posted: Tue Dec 02, 2003 6:24 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
You can "listening" directly to the message queue, but maybe should be better have the INITQ/MessageQueue configuration, so your program could use the facilities of be triggered, like:
- your program will not be running all the time, the trigger monitor will (small and specific code, no "business rules", etc)
- Your program could be used to get messages coming from another queue manager or another queue in the same queue manager, once you have these parameters in the MQTMC header
I've already had problems listening MQ message queues for long time. Depends on the MQ version in MVS you can face some weird queue manager behavious when quiescing.
Trigger monitor under MMC has an unstable behavior also.
Rgds,
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 02, 2003 6:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
But a trigger monitor is just a program "listening" on the INITQ - it can and does have exactly the same problems.
We use the IBM Windows Service client trigger monitor and it goes wrong fairly regularly. I recommend running the triggered application program on a schedule in addition, so that if triggering fails then it will at least catch the outstanding messages at some point (eg once an hour).
Also unless you have a timed/scheduled execution the trigger condition may not be reset after a trigger monitor failure (assuming you have trigger as first) as the queue will never go from 0 to 1 messages again until it has been cleared down.
For a high volume, critical application the most reliable and scalable design is to have several applications programs listening (ie MQGET WAIT) on the target application queue at the same time.
Also make sure your system management tool detects any queue depth build up so you can take corrective action. |
|
| Back to top |
|
|
| emiranda |
| Posted: Tue Dec 02, 2003 7:11 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| Quote: |
| But a trigger monitor is just a program "listening" on the INITQ - it can and does have exactly the same problems. |
But you're not listening a message queue and your trigger can be improved in the error handle, so you can make decisions (read directly, etc) depends on the error (trigger error, etc).
The trigger=every option works quite good with get exclusive.
Of course is much better if you can access the queues timed, but in case you can't, I recommend running the "triggered monitor arquitecture" instead of a listening program.
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 03, 2003 3:14 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Trigger=every means that an application program instance will be started for each message. This can overload your server if a lot of messages arrive at once. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 03, 2003 5:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| zpat wrote: |
| Trigger=every means that an application program instance will be started for each message. This can overload your server if a lot of messages arrive at once. |
In addition, it is not guaranteed that you will get one trigger message for every message on the queue. There are circumstances where the system will not create what it thinks is a "duplicate" trigger message.
Trigger=Every also equals "Not best practice".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| emiranda |
| Posted: Wed Dec 03, 2003 6:21 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Hi guys.
There's a thousand of ways to solve infrastructure problems and design it. I would never say some solution is "Not best practice". Maybe I just didn't have figured out all the scope it may offers.
We have a good and robust solution working very well in an OS/390-W2K-Solaris environment where OS/390 is the server and the other boxes are clients, running clients applications, trigger=every, controlling the way they are started and if they are already running, etc, etc...
Depends on the effort and time you can dedicate to it!
Rgds
 
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 03, 2003 5:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
There are valid reasons to use Trigger Every, although they are few and far between. Most times that I have seen Every used, it has been because something else was not right, and the person found that Every seemed to solve the problem, unaware of the drawbacks.
(Eduardo, I am not implying that you are incorrect in choosing Every, as I do not know your complete situation. You may very well need to use Every.)
If you choose Every, you *MUST* code your triggered app to read the queue until it is empty. You cannot design the app thinking that each instance of the app started will read only one message and end. This is because you risk a rolling backlog of messages if you ever find the queue with more messages than 0. By design, Every does not create a trigger message for every message on the queue, it create a trigger message for ANY message on the queue. For instance, if you ever find yourself with let's say 10 messages on the queue, and Message 11 lands, only ONE trigger message is generated, and the triggered app gets one message, the first one. Messages 2 thru 11 stay behind, until message #12 lands, at which time the triggered app reads message #2.
This will eventually happen - guaranteed. You cannot asssume your queue will never back up due to some problem. If you code your triggered Every apps to read until the queue is empty, you will not have this rolling backlog problem. And in 99% of the cases, they will start, process the one message, and go back to the queue only to find it empty. When there is a problem, they will keep going back to flush the queue empty.
Trigger OnFirst handles this nicely, in that every time you go to close the queue, even if you only processed one message, you will automatically get retriggered if there are still messages on the queue.
Of course if an app takes 2 seconds to process a message, and 100 land within 2 seconds, make sure your server can handle 100 instances of your app running at the same time! But first decide if you really need to handle ALL those messages in 2 seconds, or can thay all wait their turn. If they can wait, use Trigger First (with a good TriggerInterval value set).If they can't, maybe you need Every, or maybe you need multiple instances of the servicing app all Waiting on the queue all the time to process these messages ASAP.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kman |
| Posted: Wed Dec 03, 2003 11:00 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Trigger FIRST only works when the queue depth turns from 0 to 1. If there are messages on the queue, the trigger FIRST only works on the first message. If they was a failure somewhere and the message was returned, the depth is no longer 0, and the subsequent message that arrives will not trigger anymore.
If the trigger interval is use, it can be set to behave like a trigger every. A low value on the trigger interval would make it behave like an EVERY.
There is also a problem with synchronisation. If you set it FIRST, then there was a failure, the message is returned back, trigger reset. App starts again, pick up message, failure, return back. Trigger reset.... it goes into a loop!
.. is this correct? What do you think of this? |
|
| Back to top |
|
|
| emiranda |
| Posted: Thu Dec 04, 2003 3:16 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
You're right Peter.
We had good reasons to use trigger every and it's working very well (up till now!), in despite of you need more effort to control application/trigger behaviour.
I have to go all the way with you there's few situations where trigger every fits well, but sometimes it has to be considered.
Thanks & rgds,
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| royr |
| Posted: Thu Dec 04, 2003 4:26 am Post subject: |
|
|
Acolyte
Joined: 30 Jun 2001
Posts: 65
Location: Israel
|
| kman wrote: |
| Trigger FIRST only works when the queue depth turns from 0 to 1. If there are messages on the queue, the trigger FIRST only works on the first message. If they was a failure somewhere and the message was returned, the depth is no longer 0, and the subsequent message that arrives will not trigger anymore. |
The API Guide actually says here (see 12) that if the only application serving a queue issues an MQCLOSE call, and there are more messages in the queue, the trigger will be regenerated. That makes FIRST somewhat like EVERY, as Peter said. This way, the queue serving application can process one message at a time and get retriggered if there are more messages.
| kman wrote: |
| There is also a problem with synchronisation. If you set it FIRST, then there was a failure, the message is returned back, trigger reset. App starts again, pick up message, failure, return back. Trigger reset.... it goes into a loop! |
Correct - that's called a "poison message" and the programmer has to handle it by checking the BackoutCount field in the MQMD. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
