| Author |
Message
|
| mitches9 |
 Posted: Tue Jul 16, 2002 5:36 am Post subject: Triggering and Application |
 |
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
This seems pretty basic to me, and I've gone over my configurations many, many times, but I must be missing something. I'm trying to trigger an application any time messages arrive in a queue (trigger set to every), but I cannot get the trigger to fire off the application to save my life. I'm posting the configuration below if someone can provide me with some insight? Messages arrive in TIER3.BROADCAST.LOCAL and should drop a trigger message in LOCAL.INITQ using the BROADCAST.MSG process for application info. I'm not seeing any messages in LOCAL.INITQ after messages arrive in BROADCAST. Any suggestions for troubleshooting would be equally appreciated. (This is MQSeries 5.3 on Windows 2000, BTW).
Thanks,
Steve
dis ql(tier3.broadcast.local)
1 : dis ql(tier3.broadcast.local)
AMQ8409: Display Queue details.
DESCR( ) PROCESS(BROADCAST.MSG)
BOQNAME( ) INITQ(LOCAL.INITQ)
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(TIER3.BROADCAST.LOCAL)
CRDATE(2002-07-11) CRTIME(09.30.02)
ALTDATE(2002-07-12) ALTTIME(10.03.48)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(100) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(NORMAL) TRIGGER
TRIGTYPE(EVERY) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(0)
OPPROCS(0) CURDEPTH(0)
dis ql(local.initq)
3 : dis ql(local.initq)
AMQ8409: Display Queue details.
DESCR( ) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(LOCAL.INITQ)
CRDATE(2002-07-11) CRTIME(09.30.02)
ALTDATE(2002-07-11) ALTTIME(09.30.02)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(4) DEFPSIST(NO)
MAXDEPTH(640000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(NORMAL) NOTRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(0)
OPPROCS(0) CURDEPTH(0)
dis process(broadcast.msg)
4 : dis process(broadcast.msg)
AMQ8407: Display Process details.
DESCR( )
APPLICID(C:\Program Files\Broadcast\Broadcast.exe)
USERDATA( ) ENVRDATA( )
PROCESS(BROADCAST.MSG) ALTDATE(2002-07-11)
ALTTIME(09.29.58) APPLTYPE(WINDOWSNT) |
|
| Back to top |
|
 |
| wilsonho3 |
| Posted: Tue Jul 16, 2002 6:01 am Post subject: |
|
|
Voyager
Joined: 20 Nov 2001
Posts: 98
Location: Hong Kong
|
| Do you run the triggering monitoring task ? |
|
| Back to top |
|
|
| mitches9 |
| Posted: Tue Jul 16, 2002 9:10 am Post subject: Trigger Monitor |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
| Good question - yes I am running a trigger monitor on LOCAL.INITQ. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 16, 2002 9:12 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Can you run it in the foreground so you can see the actual output from the trigger monitor? This is usually verbose, and will clearly show whether or not a trigger message is being generated (since it will be consumed so quickly by the trigger monitor, you'll never see the depth of the INITQ go from 0 to 1...)
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 16, 2002 4:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
if u wanna prove to yourself that the QM is in fact generating trigger messages, have an app other than the trigger monitor open the queue for input, but not actual do a get (or go a get specifying a bogus correlid).
The QM will see that the IPROCS of the init queue is greater than zero, so it assumes a trigger monitor has it open. Your trigger message will pile up for you to inspect at your leisure.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Jul 16, 2002 10:19 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
First you should define the process so that it triggers your application in a new process outside of the trigger monitor. If you do not do this, the trigger monitor will get blocked until your application ends (and subsequent trigger messages will pile up in the initiation queue).
| Code: |
Replace
C:\Program Files\Broadcast\Broadcast.exe
with
START "C:\Program Files\Broadcast\Broadcast.exe" /B |
(because there is a white space in the path you may need to add quotes but I am not sure)
Second, the trigger monitor gets the messages under syncpoint so with the current definition, in case there is a problem in your app: you see no message in the queue and the trigger monitor is blocked.
Follow the advice of Brandon: run the trigger monitor interactively and see what happens, you will learn a lot from it:
| Code: |
| runmqtrm -q local.initq |
Third point, if broadcast.exe is an interactive application, it will not run if you start the trigger monitor as a service, but it will run if you start the trigger monitor interactively. I have experimented it myself by defining a process that runs "Notepad". Honnestly I cannot explain what you have to do to make it run with a service. But I understand the limitation: when the trigger monitors is started as a service, it will run whether a user is logged on or not, so defining a process associated to an interactive application does not make sense.
Fourth point, related to the previous one, make sure that the broadcast.exe has the user profile you need when it is started by the trigger monitor.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| mitches9 |
| Posted: Wed Jul 17, 2002 4:46 am Post subject: No MSGS in INITQ |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
| Thanks for all the good feedback. One thing I failed to mention was that if I turn off my trigger monitor, I don't get any messages in the INITQ (unless they're hidden from view in MQSeries Explorer). Pretty critical piece of info, sorry. So I'm thinking config problem with the BROADCAST queue? |
|
| Back to top |
|
|
| mitches9 |
| Posted: Wed Jul 17, 2002 5:17 am Post subject: Solved! |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
| Thanks again for the help guys. I ran the trigger monitor interactively and found that this issue is, in fact, that the trigger is getting hung up on my appliction completing. I'll fiddle around and try launching via START. |
|
| Back to top |
|
|
| mitches9 |
| Posted: Wed Jul 17, 2002 5:39 am Post subject: Still have a problem... |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
| Ok, I thought this was resolved but... When I run an interactive trigger monitor my setup works great. However, when I use a trigger monitor setup via the MQSeries Services console (indicating the same LOCAL.INITQ) the monitor is picking up messages and failing to launch my application. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 17, 2002 6:53 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Two things:
1) Earlier you mentioned that you turned off the trigger monitor and noticed no trigger messages on the initq. This is because one of the requirements for triggering to occur is that someone is actually listening on the initq. In other words, as soon as you turn off the trigger monitor, you'll never see trigger messages even if the trigger conditions appear to be met. This fact is a source of confusion for a lot of people...
2) I've had the exact same problem in the past. Run the trigger monitor by hand and it works, run it at startup or in the background, and it doesn't. This happened to me on UNIX, but the same issue can apply on windows. Basically it is the fact that the environment in which the trigger monitor runs is different in the two cases. For instance, on UNIX, if I want my trigger monitor to start automatically in inittab when the system is booted, it will be run before certain environment variables are set, and will in fact run without any environment variables that might be set in user mqm's shell account... These are just a couple examples. You should look very closely at the environment that is available to the trigger monitor. Does it need a PATH, CLASSPATH, etc... ?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mitches9 |
| Posted: Fri Jul 19, 2002 5:48 am Post subject: |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
Thanks for clearing up #1.
I'm starting the trigger monitor built into MQSeries Services. Any suggestions on how to check what account it starts under (would it be MUSR_MQADMIN)? I'm not running any applications with restricted access (i.e. anyone with access to the box should be able to run it). |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jul 19, 2002 6:41 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
The trick I use is have your trigger start a batch file instead of your application. The batch file will simply print out the environment, and the name of who it is running as. You can compare this to the environment you expect it to have...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mitches9 |
| Posted: Tue Jul 23, 2002 11:08 am Post subject: |
|
|
Novice
Joined: 07 Jun 2002
Posts: 23
Location: Ohio
|
| I finally figured this one out. It wasn't a permissions issue so much as a GUI one. I was trying to trigger a GUI application. The Trigger Monitor running as a service can't display the GUI interface, but interactively it can. |
|
| Back to top |
|
|
|
|
