| Author |
Message
|
| MikeClark |
 Posted: Tue Nov 25, 2008 2:18 pm Post subject: Queues not triggering... |
 |
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
On our production WMQ server we have two queue managers, one with a set of set of production queues and the other with QA queues. The PR triggered queues trigger just fine, but the QA queues don't at all.
When I run the default tests I get the following for the triggered queues on the QA queue manager:
| Quote: |
| Triggered queue <queue-name> meets the trigger conditions but has no known active input processes |
Otherwise, the queues and their associated process definitions appear to be identical to the production versions, which work fine.
Any ideas?
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Nov 26, 2008 12:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Is there a 'dummy' application at the end of the process in QA, i.e. one that just writes out a log entry that all is well, but doesn't actually connect to the queue manager, open the queue(s), and get the messages?
_________________
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 |
|
|
| MikeClark |
| Posted: Wed Nov 26, 2008 8:25 am Post subject: |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
| exerk wrote: |
| Is there a 'dummy' application at the end of the process in QA, i.e. one that just writes out a log entry that all is well, but doesn't actually connect to the queue manager, open the queue(s), and get the messages? |
Nope. No triggering occurs. No application is started. The application does log what it is doing, optionally, and although logging is set to ON and maximum verbosity, nothing is logged. I've also watched for the process in Process Explorer, and it does not even start, then fail before starting to log (I can compare this with the production process, which visibly starts and finishes).
Nice try, though! Thanks.
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 26, 2008 9:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The PR triggered queues trigger just fine, but the QA queues don't at all. |
Is the trigger monitor application running in QA?
Are trigger messages in the initiation queue? If not, are they in the dead letter queue?
Anything in error logs?
Is the triggered qlocal a new queue in QA?
_________________
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 |
|
|
| kevinf2349 |
| Posted: Wed Nov 26, 2008 9:55 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Can you post the relevant definitions? It may help to throw some light on things. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 26, 2008 10:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Look at the triggered queue in QA. Is the IPROCS count greater than 0, indicating something has it open for GETs? If yes, triggering conditions are not beeing met. Common problem in a test environment when those developers leave the queue open by one of their browsing tools.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MikeClark |
| Posted: Wed Nov 26, 2008 10:34 am Post subject: |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
| bruce2359 wrote: |
| Quote: |
| The PR triggered queues trigger just fine, but the QA queues don't at all. |
Is the trigger monitor application running in QA? |
Yes.
| bruce2359 wrote: |
| Are trigger messages in the initiation queue? If not, are they in the dead letter queue? |
Trigger messages are in the local queue.
| bruce2359 wrote: |
| Anything in error logs? |
Not a thing.
| bruce2359 wrote: |
| Is the triggered qlocal a new queue in QA? |
Yes, it is. It's not the only one, and none of the triggered queues actually trigger in QA.
Here's the Qmgr definition:
| Code: |
QMNAME(QQM) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTMQI(OFF)
ACCTQ(OFF) ACTIVREC(MSG)
ALTDATE(2008-10-29) ALTTIME(09.49.05)
AUTHOREV(DISABLED) CCSID(437)
CHAD(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHLEV(DISABLED)
CLWLDATA( ) CLWLEXIT( )
CLWLLEN(100) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CMDLEVEL(600)
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CRDATE(2008-07-31)
CRTIME(09.48.53) DEADQ(SYSTEM.DEAD.LETTER.QUEUE)
DEFXMITQ( ) DESCR( )
DISTL(YES) INHIBTEV(DISABLED)
IPADDRV(IPV4) LOCALEV(DISABLED)
LOGGEREV(DISABLED) MAXHANDS(256)
MAXMSGL(4194304) MAXPRTY(9)
MAXUMSGS(10000) MONACLS(QMGR)
MONCHL(OFF) MONQ(OFF)
PERFMEV(DISABLED) PLATFORM(WINDOWSNT)
QMID(QQM_2008-07-31_09.48.53) REMOTEEV(DISABLED)
REPOS( ) REPOSNL( )
ROUTEREC(MSG) SCHINIT(QMGR)
SCMDSERV(QMGR) SSLCRLNL( )
SSLCRYP( ) SSLEV(DISABLED)
SSLFIPS(NO)
SSLKEYR(C:\Program Files\IBM\WebSphere MQ\qmgrs\QQM\ssl\QQM)
SSLRKEYC(0) STATACLS(QMGR)
STATCHL(OFF) STATINT(1800)
STATMQI(OFF) STATQ(OFF)
STRSTPEV(ENABLED) SYNCPT
TRIGINT(999999999) |
QLocal definition:
| Code: |
QUEUE(OFM.QQM.SWV.TRIM.QL) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2008-11-25)
ALTTIME(14.44.42) BOQNAME( )
BOTHRESH(0) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) CLWLUSEQ(LOCAL)
CRDATE(2008-08-14) CRTIME(10.21.05)
CURDEPTH(1) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(YES)
DEFSOPT(SHARED) DEFTYPE(PREDEFINED)
DESCR(TRIM Queue) DISTL(NO)
GET(ENABLED) HARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0) MAXDEPTH(5000)
MAXMSGL(4194304) MONQ(QMGR)
MSGDLVSQ(PRIORITY) TRIGGER
NPMCLASS(NORMAL) OPPROCS(0)
PROCESS(OFM.QQM.SWV.TRIM.PROCESS) PUT(ENABLED)
QDEPTHHI(80) QDEPTHLO(20)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QDPMAXEV(ENABLED) QSVCIEV(NONE)
QSVCINT(999999999) RETINTVL(999999999)
SCOPE(QMGR) SHARE
STATQ(QMGR) TRIGDATA( )
TRIGDPTH(1) TRIGMPRI(0)
TRIGTYPE(FIRST) USAGE(NORMAL)
|
The TRIGDPTH is 1, and the message is a valid test message. It just sits there.
And the process definition:
| Code: |
PROCESS(OFM.QQM.SWV.TRIM.PROCESS) APPLTYPE(WINDOWSNT)
APPLICID(C:\Program Files\TRIM\QA\TRIMTriggerProcessor.exe)
ENVRDATA(OFM.QQM.SWV.TRIM.HOLDING.QL) USERDATA( )
DESCR( ) ALTDATE(2008-11-25)
ALTTIME(13.35.56) |
The applid points to an application that is identical to the one being pointed to by the PR process definition. I have also changed this so that it pointed at the PR applid and it made no difference.
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 26, 2008 10:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MikeClark wrote: |
| bruce2359 wrote: |
| Quote: |
| The PR triggered queues trigger just fine, but the QA queues don't at all. |
Is the trigger monitor application running in QA? |
Yes.
|
How do you know? What proof do you have?
Check out this link, and go thru each item one by one, to verify that trigger conditions are being met:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg13860_.htm
TRIGDPTH is not considered when the triggger type is On First. Its only used for Triiger Type Depth.
Trigger Type On First does not mean the q triggers anytime there is a message on the queue. It means if all other trigger conditions are met, the trigger message will be generated when the depth goes from 0 to 1. If the depth is already at 1, another trigger message can be generated if Trigger Interval expires AND another message arrives.
There are other ways to kick start a trigger message, if all other trigger conditions are met. For example, turn triggering of and back on for that queue.
If the app message sitting on that q is not commited, the trigger message is sitting in the init q not commited either. What is the depth and IPROCS of the INITQ?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 26, 2008 11:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| none of the triggered queues actually trigger in QA. |
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Nov 26, 2008 11:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
| none of the triggered queues actually trigger in QA. |
|
This in reply to which question / comment?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 26, 2008 11:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| none of the triggered queues actually trigger in QA. |
This leads to more questions, like:
Is the QA qmgr new?
Has it ever worked before?
What has changed?
Does anything run successfully in QA (triggered or not)?
Did poster run IVPs for this qmgr?
_________________
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 |
|
|
| MikeClark |
| Posted: Wed Nov 26, 2008 11:25 am Post subject: |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
| bruce2359 wrote: |
| Quote: |
| none of the triggered queues actually trigger in QA. |
This leads to more questions, like:
Is the QA qmgr new?
Has it ever worked before?
What has changed?
Does anything run successfully in QA (triggered or not)?
Did poster run IVPs for this qmgr? |
Answer is, this is a new queue mgr, has never successfully triggered anything. It does receive things from a remote qmgr (i.e. receive channels are working). I can also drop messages into a remote queue and have them pop up on another WMQ server.
What is an IVP?
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 26, 2008 11:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Is the trigger monitor application running in QA? |
You replied yes. Please start a trigger monitor from a c: or $ prompt. Copy and paste the interaction here.
IVP=installation verification procedure. Purpose= to validate basic functionality.
_________________
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 |
|
|
| MikeClark |
| Posted: Wed Nov 26, 2008 11:57 am Post subject: |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
| bruce2359 wrote: |
| Quote: |
| Is the trigger monitor application running in QA? |
You replied yes. Please start a trigger monitor from a c: or $ prompt. Copy and paste the interaction here.
IVP=installation verification procedure. Purpose= to validate basic functionality. |
OK, here is the interaction:
| Code: |
C:\Program Files\IBM\WebSphere MQ\bin>runmqtrm -m QQM
5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
WebSphere MQ trigger monitor started.
__________________________________________________
Waiting for a trigger message
C:\PROGRA~1\TRIM\QA\TRIMTR~1.EXE "TMC 2OFM.QQM.SWV.TRIM.QL
OFM.QQM.SWV.TRIM.PROCESS
C:\Program Files\TRIM\QA\TRIMTrigg
erProcessor.exe
OFM.QQM.SWV.TRIM.H
OLDING.QL
QQ
M " OFM.QQM.SWV.TRIM.HOLDING.QL
End of application trigger.
__________________________________________________
Waiting for a trigger message
|
There was a message waiting in one of the triggered queues. According to the above the queue triggered and the message was processed normally. Wow.
The TriggerMonitor created by default when this qmgr was created appears to be running. When you click on the Services item in Mq Explorer it is right there, and it looks the same as the production TriggerMonitor, including the greyed-out Status.
That's quite a thing -- the trigger monitor running, yet not running. When I look in Process Explorer on this machine it shows that runmqtrm is indeed running in this queue manager.
I suddenly had an idea that this trigger monitor is running against the default qmgr, because there's no start args! This would suggest that the trigger monitor is running against the default qmgr, which is PQM, not QQM.
I just tested this theory by putting -m QQM in the start args for this trigger monitor, stopping and restarting the qmgr, then dropping a message into one of the triggered queues (the manually fired trigger monitor of course closed because its qmgr stopped).
The result was that the queue now triggers normally! Woo Hoo!
So the lesson learned here is that if you're running two queue managers on the same server, you better make sure the trigger monitor is working with the expected queue manager!
Thanks for all the help, guys. 
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
|
|
