| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Lost trigger event (type EVERY) |
« View previous topic :: View next topic » |
| Author |
Message
|
| camauz |
 Posted: Thu Jun 28, 2012 11:05 pm Post subject: Lost trigger event (type EVERY) |
 |
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
Dear all,
I'm experiencing the below issue.
There's a queue with a trigger of type "EVERY"; the trigger is configured to fire a TXSeries transaction.
Sometimes we lose some trigger events, this might be what happens:
- the queue manager generates the trigger event messages
- the TXSeries region fires the transactions
- the transactions cannot immediately be executed
- the transactions go to TXSeries region internal queue
- the TXSeries region is cold restarted
- no one keeps track of the deleted transactions.
How can I force the queue manager to generate again the trigger events? It seems:
- trigger OFF / trigger ON does not work
- "trigger interval" queue manager property applies only to "TRIGGER FIRST"
All the stuff is running inside IBM AIX, if it could be relevant.
Any suggestion will be appreciated.
Thanks in advance.
Ch. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jun 29, 2012 12:27 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
IMHO, trigger off / on should work, although (i hope i am right here) it will only create 1 trigger message even if there are more than one message on a "every" - triggered queue.
However, other conditions must be fullfilled too, e.g. no consumer (open for input) on the application queue, get enabled, trigger monitor running (initq opened for input) and others.
maybe worth to re-check the trigger conditions .....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 29, 2012 1:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Mr Butcher wrote: |
| ...although (i hope i am right here) it will only create 1 trigger message even if there are more than one message on a "every" - triggered queue... |
I'm pretty sure it will generate one trigger message for each message on the queue, otherwise logic dictates there'd be no difference between FIRST and EVERY.
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Jun 29, 2012 5:30 am Post subject: Re: Lost trigger event (type EVERY) |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| camauz wrote: |
Sometimes we lose some trigger events, this might be what happens:
- the queue manager generates the trigger event messages
- the TXSeries region fires the transactions
- the transactions cannot immediately be executed |
How do you know that transactions cannot immediately be executed? What are the symptoms? What errors are logged?
| camauz wrote: |
- the transactions go to TXSeries region internal queue
- the TXSeries region is cold restarted
- no one keeps track of the deleted transactions. |
By 'TXSeries region internal queue' do you mean TSQ (Temporary Storage Queue)? Or something else? Why cold-start?
| camauz wrote: |
How can I force the queue manager to generate again the trigger events? It seems:
- trigger OFF / trigger ON does not work
|
For TRIGTYPE(EVERY), a trigger event message will be generated for each message put to the triggered queue (presuming that all other trigger conditions are met).
Are there messages in the triggered queue? Do they satisfy trigger conditions? Post the definition of the triggered queue here.
_________________
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.
Last edited by bruce2359 on Fri Jun 29, 2012 5:34 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 29, 2012 5:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Mainframe and CICS forum.
_________________
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 |
|
|
| cicsprog |
| Posted: Fri Jun 29, 2012 7:06 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
As said, post your trigger def here.
What's the Q Depth limit on this Q? You may have trigger msgs being generated but trigger msgs going to the DLQ (assuming you have a DLQ defined). |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 29, 2012 9:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| Mr Butcher wrote: |
| ...although (i hope i am right here) it will only create 1 trigger message even if there are more than one message on a "every" - triggered queue... |
I'm pretty sure it will generate one trigger message for each message on the queue, otherwise logic dictates there'd be no difference between FIRST and EVERY. |
Nope. Only one.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
| Quote: |
Note:
1.From step 12 (where trigger messages are generated as a result of some event other than a message arriving on the application queue), the trigger message is not put as part of a unit of work. Also, if the TriggerType is MQTT_EVERY, and if there are one or more messages on the application queue, only one trigger message is generated.
|
One of the many drawbacks to EVERY compared to On FIRST.
Its crucial that apps triggered by every read until the queue is empty. Then it doesn't matter if you only get one trigger message in this case - the queue will be drained.
camauz,
Please explain why you think you need trigger type Every and not On First. Simply saying I want a trigger message for each message is not a good enough reason, and its not possible 100% of the time to get one trigger message for each app message anyway as you've just found out.
If your triggered every app is not written to read until the q is empty its not a question of if but when you will get into a rolling backlog where your trigger messages have fallen behind your app messages in the queue.
Trigger On First has extra features that allow it to self recover from a number of conditions that cause issues for Trigger Every. Most can be mitigated by just reading until the q is empty though.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 29, 2012 10:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| exerk wrote: |
| Mr Butcher wrote: |
| ...although (i hope i am right here) it will only create 1 trigger message even if there are more than one message on a "every" - triggered queue... |
I'm pretty sure it will generate one trigger message for each message on the queue, otherwise logic dictates there'd be no difference between FIRST and EVERY. |
Nope. Only one.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
| Quote: |
Note:
1.From step 12 (where trigger messages are generated as a result of some event other than a message arriving on the application queue), the trigger message is not put as part of a unit of work. Also, if the TriggerType is MQTT_EVERY, and if there are one or more messages on the application queue, only one trigger message is generated.
|
One of the many drawbacks to EVERY compared to On FIRST.
Its crucial that apps triggered by every read until the queue is empty. Then it doesn't matter if you only get one trigger message in this case - the queue will be drained.
camauz,
Please explain why you think you need trigger type Every and not On First. Simply saying I want a trigger message for each message is not a good enough reason, and its not possible 100% of the time to get one trigger message for each app message anyway as you've just found out.
If your triggered every app is not written to read until the q is empty its not a question of if but when you will get into a rolling backlog where your trigger messages have fallen behind your app messages in the queue.
Trigger On First has extra features that allow it to self recover from a number of conditions that cause issues for Trigger Every. Most can be mitigated by just reading until the q is empty though. |
Triggering is confusing.
| Quote: |
Note:
1.From step 12 (where trigger messages are generated as a result of some event other than a message arriving on the application queue), the trigger message is not put as part of a unit of work. Also, if the TriggerType is MQTT_EVERY, and if there are one or more messages on the application queue, only one trigger message is generated. |
You must read this very, very, very carefully.
This is a very specific set of circumstances when a trigger event message will NOT be generated (for each message).
- TRIGTYPE(EVERY); and
- trigger messages are generated as a result of some event other than a message arriving on the application queue; and
- there are one or more messages on the application queue
_________________
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 |
|
|
| camauz |
| Posted: Wed Jul 04, 2012 4:35 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
| PeterPotkay wrote: |
| exerk wrote: |
| Mr Butcher wrote: |
| ...although (i hope i am right here) it will only create 1 trigger message even if there are more than one message on a "every" - triggered queue... |
I'm pretty sure it will generate one trigger message for each message on the queue, otherwise logic dictates there'd be no difference between FIRST and EVERY. |
Nope. Only one.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
|
Unfortunately this seems to be the real effect of TRIGGER OFF/TRIGGER ON experimented on a lab system.
| Quote: |
| Quote: |
Note:
1.From step 12 (where trigger messages are generated as a result of some event other than a message arriving on the application queue), the trigger message is not put as part of a unit of work. Also, if the TriggerType is MQTT_EVERY, and if there are one or more messages on the application queue, only one trigger message is generated.
|
One of the many drawbacks to EVERY compared to On FIRST.
Its crucial that apps triggered by every read until the queue is empty. Then it doesn't matter if you only get one trigger message in this case - the queue will be drained.
camauz,
Please explain why you think you need trigger type Every and not On First. Simply saying I want a trigger message for each message is not a good enough reason, and its not possible 100% of the time to get one trigger message for each app message anyway as you've just found out.
|
We choosed trigger type Every because we process many messages with some parallelism degree (3..6). The TXSeries class associated to the transaction caps the maximum number of parallel tasks. If I used trigger FIRST I should develop by myself some TPmonitor feature to inspect the triggered queue and span more than one transaction. I prefer the "out of the can" solution provided by WebSphere MQ and TXSeries.
| Quote: |
If your triggered every app is not written to read until the q is empty its not a question of if but when you will get into a rolling backlog where your trigger messages have fallen behind your app messages in the queue.
|
That's the point: we are planning to improve the application and implement a GET loop as we do with other trigger FIRST use cases
| Quote: |
Trigger On First has extra features that allow it to self recover from a number of conditions that cause issues for Trigger Every. Most can be mitigated by just reading until the q is empty though. |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 04, 2012 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remember also that for better efficiency a triggered program should do a get with wait with a reasonnable wait time... so as to catch and process the next message... before exiting on no more messages on queue...(2033)... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Jul 04, 2012 9:43 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
In addition, there is a recommendation that a program triggered with "every" should read till end of queue, and not only just 1 msg. Thats also due to the fact that a trigger off / on, or a trigger monitor start while there are already messages on the queue triggered every will create only 1 trigger message.
_________________
Regards, Butcher |
|
| 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
|
|
|
|
