| Author |
Message
|
| sijtom0703 |
 Posted: Tue Dec 06, 2011 1:01 am Post subject: Trigger stops working when DB connection fails |
 |
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
I have an issue where a Triggering set in Application Queue for FIRST stops working whenever we get a
| Quote: |
| Database connection failed: Timeout expired (State:S1T00,Native:0,Origin:[Microsoft][ODBC SQL Server Driver] ). |
The messages get stuck in the Queue until I do a recycling for Trigger setup:
Off the Trigger and On it again through MQ Explorer.
Is there anything I can do so that the Triggering will start automatically when the Application Database Connection is restored
Platform: Windows 2003 Server
Software: WebSphere MQ v 7.0.1
Please advice! |
|
| Back to top |
|
 |
| shashivarungupta |
| Posted: Tue Dec 06, 2011 1:54 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
I have faced such scenario when you set trigger type FIRST. I took it as a disadvantage of trigger type FIRST when first msg is not being consumed/processed then for any next message trigger wont happen because you have instructed that trigger should happen only when queue depth goes to 1 from 0.
What do you do with the msg on the queue, when you set trigger off and then on ?
Why don't you try doing it with trigger type EVERY.
Also please check why there is timeout when you try to connect to db !
As a suggestion, you should be giving as much as information here for better results/clues !
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Dec 06, 2011 2:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| I have faced such scenario when you set trigger type FIRST. I took it as a disadvantage of trigger type FIRST when first msg is not being consumed/processed then for any next message trigger wont happen because you have instructed that trigger should happen only when queue depth goes to 1 from 0. |
It's a disadvantage how?
| shashivarungupta wrote: |
| What do you do with the msg on the queue, when you set trigger off and then on ? |
He/she does nothing, but the application will, or not if it can't get to the DB.
| shashivarungupta wrote: |
| Why don't you try doing it with trigger type EVERY. |
Great idea! Why not potentially have multiple instances of the application hanging on a DB connection? 
| shashivarungupta wrote: |
| Also please check why there is timeout when you try to connect to db ! |
Presumption. It could be a timeout, but it could also be a broken connection, but also the first useful bit of advice you've offered.
| shashivarungupta wrote: |
| As a suggestion, you should be giving as much as information here for better results/clues ! |
As a suggestion, you could give better advice than changing the trigger type, maybe pointing the poster towards research of TRIGINT perhaps?
sijtom0703, would I be right in thinking that your application gets the failed connection message, then ends? If so, you might want to consider changing its behaviour to retry the connection a number of times before deciding to end.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Tue Dec 06, 2011 3:15 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| I have faced such scenario when you set trigger type FIRST. I took it as a disadvantage of trigger type FIRST when first msg is not being consumed/processed then for any next message trigger wont happen because you have instructed that trigger should happen only when queue depth goes to 1 from 0. |
It's a disadvantage how? |
as I said, (for example) if there is requirement to have an appl. process to be triggered on every incoming message then why to choose first trigger type. Say your trigger monitor ends accidentally and a msg comes to the queue which is not then processed by trigger monitor, you identify later that oops..there is a problem with trigger mon and you make it start, you don't clear the msg from the queue and msgs were still coming to the queue which should trigger the process, but it wont because curdepth of queue by then would be greater then 1, whereas first trigger type would work when curdepth goes from 0 to 1. (just an example).
But here if he/she has the requirement to have first as trigger type then there would be some logic behind it (I assume).
| exerk wrote: |
| shashivarungupta wrote: |
| What do you do with the msg on the queue, when you set trigger off and then on ? |
He/she does nothing, but the application will, or not if it can't get to the DB. |
Understand but what if msg is not being picked up/handled by appli. or db , and he/she Identifies that msg is still on the queue ?
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Dec 06, 2011 3:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| as I said, (for example) if there is requirement to have an appl. process to be triggered on every incoming message then why to choose first trigger type. |
A facile statement - if there was a requirement to trigger on every incoming message then not choosing every would not be meeting requirement.
| shashivarungupta wrote: |
| Understand but what if msg is not being picked up/handled by appli. or db , and he/she Identifies that msg is still on the queue ? |
Another facile statement. If the application requirement is to get a message, process it, and update a DB (possibly two-phased, but not necessarily) then the sensible thing for an application to do if it can't get to the DB is leave the message on the queue. Application of a little thought and logic can go a long way to preempting certain questions.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Dec 06, 2011 4:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| shashivarungupta wrote: |
as I said, (for example) if there is requirement to have an appl. process to be triggered on every incoming message then why to choose first trigger type. Say your trigger monitor ends accidentally and a msg comes to the queue which is not then processed by trigger monitor, you identify later that oops..there is a problem with trigger mon and you make it start, you don't clear the msg from the queue and msgs were still coming to the queue which should trigger the process, but it wont because curdepth of queue by then would be greater then 1, whereas first trigger type would work when curdepth goes from 0 to 1. (just an example).
But here if he/she has the requirement to have first as trigger type then there would be some logic behind it (I assume).
|
You need to review the trigger conditions that cause a trigger message to be created by the Queue Manager. There are many different scenarios that will cause a QM to generate a trigger message on a Trigger On First queue when the queue depth is not going from 0 to 1, including the scenario you specifically mention.
You should also review what Trigger Interval is.
9 out of 10 times, Trigger Every is incorrectly in use. 99 out of 100 times people using Trigger Every don't realize the drawbacks and nuances this trigger mode has.
Over the years there have been a lot of in depth discussions on this very topic on this site. Happy searching and reading.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 06, 2011 4:15 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| shashivarungupta wrote: |
| ...Say your trigger monitor ends accidentally and a msg comes to the queue which is not then processed by trigger monitor, you identify later that oops..there is a problem with trigger mon and you make it start, you don't clear the msg from the queue and msgs were still coming to the queue which should trigger the process, but it wont because curdepth of queue by then would be greater then 1, whereas first trigger type would work when curdepth goes from 0 to 1. |
Yes, TRIGTYPE(FIRST) is designed to trigger when depth goes from 0 to 1. But, the qmgr triggering mechanism is clever enough to recognize that a trigger should have fired, but didn't; and it will fire the trigger with current depth greater than 0.
_________________
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 |
|
|
| sijtom0703 |
| Posted: Wed Dec 07, 2011 9:47 pm Post subject: |
|
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
Hi
Thanks for all the replies!
Since I am working only on Administration of MQ I do not have much insight into how Application works and Application logs. I will check with Application Team
We have reduced the TRIGINT value to 300000 milliseconds. But what I do not understand here is every time we get this issue when I recycle Trigerring through MQ Explorer it starts working and messages stuck in Application Queue are consumed. Otherwise messages gets piled up in the Queue even after the TRIGINT time is passed and Application restores DB connectivity.
Also when I get this error and messages are getting piled up in the Application queue there are no Trigger messages in INITQ (SYSTEM.DEFAULT.INITIATION.QUEUE).
As far as I know we have to Trigger for every messages. I will try whether EVERY works for this situation |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 07, 2011 10:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| sijtom0703 wrote: |
| But what I do not understand here is every time we get this issue when I recycle Trigerring through MQ Explorer it starts working and messages stuck in Application Queue are consumed. Otherwise messages gets piled up in the Queue even after the TRIGINT time is passed and Application restores DB connectivity. |
TRIGTYPE(DEPTH) is working as documented. With TRIGTYPE(DEPTH), when the trigger fires, the qmgr turns TRIGGER to NOTRIGGER. The application must issue an MQSET call to enable triggering.
| sijtom0703 wrote: |
| Also when I get this error and messages are getting piled up in the Application queue there are no Trigger messages in INITQ (SYSTEM.DEFAULT.INITIATION.QUEUE). |
Working as documented. If triggering is set to NOTRIGGER, as it will be when the trigger fires for TRIGTYPE(DEPTH), no more trigger messages will be generated.
| sijtom0703 wrote: |
| As far as I know we have to Trigger for every messages. I will try whether EVERY works for this situation |
TRIGTYPE(FIRST) should work for you.
Please read the relevant sections of the WMQ Application Programming Reference and WMQ Application Programming Guide - or the InfoCenter equivalents - for TRIGTYPE(DEPTH).
_________________
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 |
|
|
| Vitor |
| Posted: Thu Dec 08, 2011 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sijtom0703 wrote: |
| As far as I know we have to Trigger for every messages. I will try whether EVERY works for this situation |
It will work. It will work so well your server will crash due to resource shortage if a high number of messages turn up. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 08, 2011 12:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Does your trigger put the process into the background or wait for it to finish?
Nothing else will trigger if your trigger waits for the DB timeout...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sijtom0703 |
| Posted: Fri Dec 09, 2011 9:50 pm Post subject: |
|
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
Thanks Bruce for providing more insight into working of TRIGGER.
I am using Trigger defined as Service in MQ and hence will be invoking the triggered application in the background |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 10, 2011 5:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| sijtom0703 wrote: |
Thanks Bruce for providing more insight into working of TRIGGER.
I am using Trigger defined as Service in MQ and hence will be invoking the triggered application in the background |
Sure but are you putting it in the background or waiting on the trigger monitor for it to finish?
In Unix the command would end with an "&"
In windows it would start with "start "....
This makes the the current shell not wait for the command to finish...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sijtom0703 |
| Posted: Sun Dec 11, 2011 8:35 pm Post subject: |
|
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
| I am using start while configuring Trigger monitor in windows. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Dec 11, 2011 9:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| sijtom0703 wrote: |
| I am using start while configuring Trigger monitor in windows. |
Huh? What?
Please display your PROCESS definition, and post it 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. |
|
| Back to top |
|
|
|
|
