Author |
Message
|
RAJESHRAMAKRISHNAN |
Posted: Mon Jan 23, 2017 9:20 pm Post subject: MQ 8.0 Queue Trigger behaviour |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hello All
We have a triggered queue in production.
Trigger type is - "for every". The trigger invokes a process that creates a zero byte file in a particular path . A job gets kick started if this zero byte size file is present. The triggered queue is not cleared automatically(It is a manual process to clear the queue). The messages are persistent.
When messages are present in the queue and queue manager is restarted, trigger message is created (Though no new message has got in to the queue). Is this an expected behavior?
Thanks
Rajesh |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Jan 23, 2017 10:44 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
you still have to read the message from the queue.
The trigger mechanism allows a non running application to be woken up/started when a message for it is ready for it.
Once triggered you still have to read the message from the queue.
It is also good practice to try to read further messages (with a timeout) from the queue once the initial message has been processed and before the application disconnects and exits. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Mon Jan 23, 2017 11:01 pm Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
Hello Davies,
Thanks for the reply. I agree that it is best practice to remove messages. Unfortunately it has been designed that way. The messages in the queue are zero byte messages and sole purpose is to create the trigger file
What I am trying to understand is whether it is expected behaviour for the Queue Manager to create an additional trigger message (For the trigger monitor to process) after queue manager is restarted. i.e even without any new message is triggered. |
|
Back to top |
|
 |
exerk |
Posted: Tue Jan 24, 2017 12:19 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
RAJESHRAMAKRISHNAN wrote: |
What I am trying to understand is whether it is expected behaviour for the Queue Manager to create an additional trigger message (For the trigger monitor to process) after queue manager is restarted. i.e even without any new message is triggered. |
Yes, it is. When each messages arrives it generates a trigger event, but each message being persistent it survives queue manager restart (of any variety), and the restart effectively resets the trigger, so hence the behaviour you're seeing.
If the queue manager restarts are planned why not turn off triggering before shut-down, clear the queue after restart, then turn on triggering? _________________ 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. |
|
Back to top |
|
 |
RAJESHRAMAKRISHNAN |
Posted: Tue Jan 24, 2017 12:35 am Post subject: |
|
|
Voyager
Joined: 01 May 2004 Posts: 96
|
That answers my question. The QM restart was not planned. We are working on solutions at present. Remove the messages once file is created and/or make the queue non persistent (Not critical message).
Thanks very much |
|
Back to top |
|
 |
gbaddeley |
Posted: Mon Jan 30, 2017 6:13 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Jan 30, 2017 11:41 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
RAJESHRAMAKRISHNAN wrote: |
That answers my question. The QM restart was not planned. We are working on solutions at present. Remove the messages once file is created and/or make the queue non persistent (Not critical message).
Thanks very much |
You could make the Queue non Persistent but that won't stop an application writing a persistent message to the Queue.
This is MQ App Dev 101 sort of stuff but it is surprising how many people do not realise it.
Making a Queue Non-Persistent will only affect applications that use the default persistent setting when writing a message to the Queue.
This can be overwritten by setting a property in the MQMD or a message property.
This is how it was designed to work.
Please just do as has been suggested by myself and gbaddely and read the message that caused the trigger from the queue. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
zpat |
Posted: Tue Jan 31, 2017 12:05 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
You must remove messages from the queue in a triggered model.
However your overall design is somewhat poor. You are triggering a queue to launch a process to create a file that starts a job. It's almost comical.
It would be better to launch a process (script) that removes the message and starts the job (maybe with a direct command to your job scheduler). You might even pass the job name in the message.
At least use the message contents to record key information about the event that created the message as this will help with auditing and debugging.
Then you would have a flexible design with fewer moving parts. Any use of "zero byte" messages or files means you are using them inappropriately. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
|