| Author |
Message
|
| atoms |
 Posted: Thu Jul 21, 2005 3:39 am Post subject: Problems with triggering |
 |
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Hi!
I'm having problem with a queue that should be triggering a VBScript (Windows 2003 Server). This has been working fine earlier but suddenly it has stopped working. Messages keep piling up on the queue, but the script that should be processing the messages does not seem to be triggered. If I place a test message on the queue, most often no trigger message is delivered to the initiation queue. Also, if a trigger message is delivered to the initiation queue the script still does not seem to be triggered. The trigger message simply remain on the initiation queue.
Is there some way to log if trigger events is generated when a message is put on a queue configured for triggering? Can I log the activity of the trigger monitor somehow?
I was thinking if the "MUSR_MQADMIN"-account perhaps did not have the right to start the script, but I have tried to add it to the Administratos group with no success. Does this change require a full reboot of the machine in order to become effective? (I'm a bit reluctant to rebooting the machine since I'm administering it from remote) I've studied chapter 14 in the "Application Programming Guide" that deals with triggering, but this did not help me solve the problem...
Thanks in advance! |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Jul 21, 2005 5:23 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| What type of triggering? (first , depth, or every). Can you post the relevant definitions? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 5:34 am Post subject: Re: Problems with triggering |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| atoms wrote: |
| Can I log the activity of the trigger monitor somehow? |
It depends on the trigger monitor.
The trigger monitor invoked from MQServices should log stuff to the regular MQ error logs.
If you are using runmqtrm or runmqtmc, it will output information to stdout, and you can redirect that into a file that you can watch (if you are running the trigger monitor in the background).
The first thing I'd do is confirm that the INIT Q still has an Open Input Count.
If it does, then I'd check my process list to see if an instance of my triggered application has gotten locked up and is holding up the trigger monitor.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 6:05 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Thanks for your response Kevin! The triggering type is set to first.
I'm not sure what exactly the "relevant definitions" are. Please, be patient with me for I'm only a newbie to MQ...  Anyway, here are some of the, hopefully relevant, definitions:
Application queue:
Trigger control=on
Trigger type=first
Trigger depth=1
Trigger Message Priority=0
Initiation queue name= points at the initiation queue
Process name=points out a process definition
Initiation queue:
The initiation queue is not set up with any special properties
A process definition is set up with the following properties:
Application type=Windows NT
Application Identifier="WScript //B D:/searchPath/scriptToBeTriggered.vbs"
A trigger monitor custom service is set up with the following properties:
Start Command=runmqtrm -m QmgrName -q NAME.OF.INITQ
End Command=runmqtrm -m QmgrName -q NAME.OF.INITQ
Execution=PROCESS
Startup=AFTER
The application queue is not open for removing messages (OpenInputCount=0) and the initiation queue is open for rmoving messages by the trigger monitor (OpenInputCount=1).
Still, it does not work!? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 6:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| atoms wrote: |
A trigger monitor custom service is set up with the following properties:
Start Command=runmqtrm -m QmgrName -q NAME.OF.INITQ
End Command=runmqtrm -m QmgrName -q NAME.OF.INITQ
Execution=PROCESS
Startup=AFTER |
You don't need the end command.
You can add "> c:\Windows\Temp\runmqtrm.txt" to the Start command to enable a log file.
| atoms wrote: |
The application queue is not open for removing messages (OpenInputCount=0) and the initiation queue is open for rmoving messages by the trigger monitor (OpenInputCount=1).
Still, it does not work!? |
Check the Task Manager to see if you see any WScript processes running, or if you see any scriptToBeTriggered processes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 6:20 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Thanks Jeff! It seems as if you are on to something! I have loads of wscript.exe-processes as well as cmd.exe started on the machine (the test machine) by "MUSR_MQADMIN".
When I look at the production machine it is the same thing but there are also a lot of processes started by "MUSR_MQADMIN" with other names such as: runmqlsr.exe, amqxssvn.exe, amqpcsea.exe, amqzlaa0.exe, amqzdmaa.exe and so on!? What are these? How could this happen, is something wrong with the script or what? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 6:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| atoms wrote: |
| Thanks Jeff! It seems as if you are on to something! I have loads of wscript.exe-processes as well as cmd.exe started on the machine (the test machine) by "MUSR_MQADMIN". |
Restart the machine, and don't trigger the app.
Compare the Task manager with what you see now.
Then trigger your app, and see what happens.
| atoms wrote: |
| When I look at the production machine it is the same thing but there are also a lot of processes started by "MUSR_MQADMIN" with other names such as: runmqlsr.exe, amqxssvn.exe, amqpcsea.exe, amqzlaa0.exe, amqzdmaa.exe and so on!? What are these? How could this happen, is something wrong with the script or what? |
Those are the MQ server processes. Don't worry about them. The only thing you're worried about is your program.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 7:01 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Ok, I restarted the machine and compared the task manager. Before there was several wscript-processes running. After the reboot the task manager looked much cleaner. I put a test message on the queue to trigger the app and it worked just fine! When I check the task manager afterwards there are no wscript-processes open.
So, the question is, what was it that made the processes go running wild? The strange thing is that the similar thing seems to have happened on both the test and the production machine. Something must have happened down there...?
That leaves me with the task to reboot the production machine...
Once again, many thanks Jeff! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 7:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| atoms wrote: |
| So, the question is, what was it that made the processes go running wild? The strange thing is that the similar thing seems to have happened on both the test and the production machine. Something must have happened down there...? |
My first, off-the-cuff and out of my hat, guess is that the app decided to display a prompt asking for input, or display an error message that needs to be "ok"'ed. Since it's running in the background, there is no way to respond to that prompt.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 9:34 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
Well, I didn't write the app so I guess it is possible. But on the other hand the app has been working fine for 2-3 years, before I got involved  , so it seems less likely.
However, I checked the production machine and although there are no wscript-processes blocking that I can see the messages still won't get procesed from the queue. On the production machine there are about 100 messages on the queue. What happens when trigger type is set to "first" and there are already several messages on the queue? I read that trigger type "first" only produces trigger events when the queue depth changes from 0 to 1 (or after a default time out period of 999999999 milliseconds).
Could this be a problem in my case? I mean, sooner or later a trigger event should be generated anyway, right? Is it possible somehow to "backup" all messages from a queue, empty the queue, try to put a test message on it to se if it works and then put the backed up messages back on the queue again (other than writing a program to read the messages from the queue, I guess)? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 9:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| atoms wrote: |
| However, I checked the production machine and although there are no wscript-processes blocking that I can see the messages still won't get procesed from the queue. On the production machine there are about 100 messages on the queue. What happens when trigger type is set to "first" and there are already several messages on the queue? I read that trigger type "first" only produces trigger events when the queue depth changes from 0 to 1 (or after a default time out period of 999999999 milliseconds). |
The easiest thing to do is alter the queue to disable triggering, and then alter it to enable triggering.
This will cause a new trigger message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 9:53 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
| Yeah, I thought so. I tried it but it still didn't help, the messages keep piling up... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 9:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
see if you can stop the trigger monitor and restart it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| atoms |
| Posted: Thu Jul 21, 2005 9:56 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2005
Posts: 27
|
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jul 21, 2005 10:44 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
We had an instance on a Windows server where we had one trigger monitor running in a DOS window and one that was running as a windows service (both watching the same init queue). The one running as a service was failing due to authorities, the DOS window one was working fine. We were getting intermitent triggers mixed with intermitent failure to tirigger....only in our case we were getting failure messages written to the AMQERR** log.
We found the process id of the windows service (using MQ Explorer, Queue Status) and killed it in Windows task manager. Everything was fine after that.
Not sure if this helps you much as you are not seeing any failure messages in the log.
You may want to changed the trigger interval on the queue manager too. The default of 999999999 is about 11 days, or in other words long, long after you have fixed the problem.
We set all our production Qmgrs to 600000 (10 minutes) |
|
| Back to top |
|
|
|
|
