| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trigger behaviour |
« View previous topic :: View next topic » |
| Author |
Message
|
| HenriqueS |
 Posted: Fri Jan 19, 2007 1:04 pm Post subject: Trigger behaviour |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
First of all, I´d like to thank all the excelente feedback I´ve gotten from the mqseries.net forum these last months.
Now, back to business.
I´ve noticed a strange (for me) behavour. I am doing some tests using MQExerciser (it´s some sort of stress tool for MQ).
Basically I am PUTing a few thousand messages to a queue.
I noticed that the trigger monitor only will actually receive events when the connection withing the client is closed. Is that right?
So, following this idea, if the client puts thousands of messages on a queue, the trigger can even be set to FIRST, but any action will be taken only when the client disconnects from that Queue leaving those thousands of messages. Is maybe MQExerciser doing some sort of exclusive operation? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jan 19, 2007 5:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That's probably because your MQExcerciser was set to open the queue in browse/inq mode. If you set it to access the queue in put mode only (ipprocs=0) you should see the trigger behavior change...
As long as the queue has any ipprocs the qmgr thinks it is being serviced and will not trigger.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 20, 2007 8:46 am Post subject: |
|
|
Guest
|
| From an applications point of view, messages MQPUT to a queue within syncpoint will not cause the trigger to fire until the MQCMIT. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Jan 22, 2007 1:12 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| From an applications point of view, messages MQPUT to a queue within syncpoint will not cause the trigger to fire until the MQCMIT. |
No. A msg put in syncpoint will cause a trigger msg immediately, as long as the other trigger conditions are met. It is not necessary for the UoW to be committed.
See note (a) under trigger condition 3:
| Quote: |
| For non-shared local queues, the queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. Consequently an application might be started when there are no messages for it to retrieve because the messages on the queue have not been committed. |
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 22, 2007 7:54 am Post subject: |
|
|
Guest
|
From the same manual:
b. For local shared queues the queue manager counts committed messages only.
There are a quite a few pages devoted to Triggers in MQ documentation (Application Programming Guide), describing under what circumstances they work, and when they go bad. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Mon Jan 22, 2007 10:51 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Thanks for the reply guys,
I have solely the Java Programming and Fundamentals books here. That´s why I ended up posting the question.
I´ve tried to download the Application Programming Guide and System Admin Guide but their downloads pages seem broke due some javascript problem in the license agreement popup. I tried to access it using IE as well Forefox and had no sucess. I am looking for a coleague running Opera.... |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Wed Jan 24, 2007 9:07 am Post subject: Back to triggering |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Folks, back to triggering....let´s say that, for some particular reason, we decided to implement our own trigger monitor to watch an init queue.
The MQ Programming Reference says:
"To a queue manager, a trigger monitor is like any other application that serves a queue. However, a trigger monitor serves initiation queues.
A trigger monitor is usually a continuously-running program. When a trigger message arrives on an initiation queue, the trigger monitor retrieves that message. It uses information in the message to issue a command to start the application that is to process the messages on the application queue."
If I watch the init queue using MQ Explorer I get nothing on the init queue while the events are actually happening. So, the programming reference seems wrong.
I see one light - the same manual says:
"The queue manager creates a trigger message when the following conditions are satisfied:
...
8 - A trigger monitor currently has the initiation queue open for removing messages (that is, the OpenInputCount local queue attribute is greater than zero)."
So I will only be able to intercept any trigger messages on my init queue if I have running an app running right away monitoring that queue and not just browsing the queue using MQ Explorer, right?
Or I am pushed to use the MQ-suplied runmqtrm utility and I never get any chance to intercept and parse the MQTM messages? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 24, 2007 9:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In order for there to be a message on the initq, some program must be polling the initq.
If some process is polling the initq, most likely any messages that appear will be removed from the queue before MQ Explorer can notice them.
If you want to examine trigger messages (and, really, they're just regular MQ messages that contain an MQTMC structure), you can write a program that either just opens the queue for input and never gets any messages, or b) that gets and prints the messages to a file or some such.
If you do a), then as long as you don't open exclusive, you'll be able to browse the trigger messages with MQ Explorer.
There are some valid reasons for writing your own trigger monitor - process level security based on message content, for example. But most of those reasons can be handled in the triggered application rather than the trigger monitor just as well. So most poeple don't bother.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
