| Author |
Message
|
| AviD |
 Posted: Tue Apr 06, 2004 6:03 am Post subject: Downtime Maintenance - Best Practices For Suspending MQ |
 |
|
Acolyte
Joined: 06 Apr 2004
Posts: 62
|
We have many applications that interface with Websphere MQ, several of which utilize MQ Triggering.
Is there a way to suspend the Trigger Montior(s) for a given time frame? Ideally, we have maintenance downtimes in which we would like to prevent any applications from being invoked by Websphere MQ Triggers.
We have implemented a sequence of stopping the MQ services, performing maintenance, and restarting the MQ services on our NT boxes (Windows 2000 AS) but have run into occassional problems with hung processes that prevent the QM from being started once the services are restarted.
Just wondering what common practice is in terms of "suspending" Websphere MQ during necessary downtime.
An alternative is to issue an alter ql(xxxxxxxx.xxxxxxxx.xxxx) notrigger to each application queue, then perform maintenance, and issue an alter ql(xxxxxxxx.xxxxxxxx.xxxx) trigger afterwards. But the scalability and general risk of the MQ infrastructure change isn't very desirable.
Any suggestions would be greatly appreciated.
Thanks ahead of time for any replies! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Apr 06, 2004 6:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why not just stop the trigger monitors?
As to hung processes, all of your applications should be coded to FAIL IF QUIESCING...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| AviD |
| Posted: Tue Apr 06, 2004 6:11 am Post subject: |
|
|
Acolyte
Joined: 06 Apr 2004
Posts: 62
|
How can you stop the trigger monitor(s) in an automated fashion? This will be a scheduled automated process, with no manual intervention.
Is there a way to programmatically stop and then restart the trigger monitor(s)? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 06, 2004 6:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Huh.
I thought amqmdain or runmqsc would let you stop a trigger monitor, but they don't.
I guess you could kill any instances of runmqtrm...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| AviD |
| Posted: Tue Apr 06, 2004 7:03 am Post subject: |
|
|
Acolyte
Joined: 06 Apr 2004
Posts: 62
|
Yeah exactly, no means to issue a clean stop of the trigger monitor(s).
I *could* write some application to identify/track the PID of the trigger monitors and kill them, but that is pretty messy and will vary from OS to OS.
Looking for something cleaner...struggling to think of anything. As an intermediate solution, I think altering the respective application queue trigger property will suffice until I can devise an alternate solution.
Any additional recommendations would be great! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 06, 2004 7:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Depending on the numbers, it may be easier to get disable (or put disable) the INITQ rather than changing the triggering on the app queue.
But there will only be a smaller number of INITQs than app queues if your app queues are sharing INITQs, which I personally prefer not to do to ensure that one app can't interfere with another app.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 06, 2004 5:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff wrote:
| Quote: |
...sharing INITQs, which I personally prefer not to do to ensure that one app can't interfere with another app.
|
Has this ever happened to you? How? I've always been taught that we only need one one trigger monitor per server where apps are to be triggered.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 06, 2004 7:00 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
Jeff wrote:
| Quote: |
...sharing INITQs, which I personally prefer not to do to ensure that one app can't interfere with another app.
|
Has this ever happened to you? |
Yes.
Single threaded runmqtrm, with apps that were not set up to run in a new process putting up an "Okay?" box in the background. If the app never quits, the next trigger message never gets processed...
| Quote: |
| I've always been taught that we only need one one trigger monitor per server where apps are to be triggered. |
I'd agree that you only need one trigger monitor per server. Is that what you want, though? Dunno.... How secure is your trigger monitor? How sure are you that you're okay if someone builds a custom MQTMC2 structure that contains "rm *.*" or similar, and puts it on the INITQ? Or have you secured your INITQs so that only the MQ system has put authority to them?
In cases where I'm really concerned about security, I would use something other than the standard MQSeries methods of launching a trigger monitor - I'd use system standard "initate a process in the background" methods and run a different trigger monitor for each application under the application ID, and ensure that the application ID didn't have rights to more system resources than it absolutely needed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Venku |
| Posted: Wed Jun 02, 2004 5:50 am Post subject: Shutdown message on the INTIQ |
|
|
Novice
Joined: 02 Jun 2004
Posts: 10
Location: Newyork
|
Did you tried to put a shutdown message on INITQUEUE ??
We had an MQSeries batch trigger monitor running on OS/390 developed using the IBM support pack, we put a shutdown message with a feed back code on the INIT QUEUE to shutdown the trigger monitor, Perform maintenance operations and re-start the trigger monitor.
I’m not sure if this feature is available on NT.
Please look at this URL
http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000076&loc=en_US&cs=utf-8&lang=en |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 02, 2004 10:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You talk about maintenance window without manual intervention. I am at a loss to understand what type of maintenance you want to perform.
What you can do is automatically shutdown the qmgrs concerned, then bring them back up without trigger monitor or leave them shutdown for your maintenance intervall and finally bring them back up with a trigger monitor at the end of the interval.
Now this may well be a problem if you have Websphere running MDBs because the process won't shut down. YOu have to keep in mind that there are dependencies. We shutdown Websphere before we shutdown Websphere MQ because of that....
Hope it helps
F.J.  |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Jun 02, 2004 11:09 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Won't GET disabling the INITQ cause the trigger monitor to stop? I thought that it would but I could be wrong. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jun 03, 2004 4:40 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Quick update
It looks like GET inhibiting the initq does cause a trigger monitor to close down. I have just tried it on a Windoze box and it worked just fine.
Of course you still have to somehow GET inhibit and GET allow the INITQ in order to automate things so you may be no further forward. |
|
| Back to top |
|
|
| Venku |
| Posted: Thu Jun 03, 2004 5:43 am Post subject: INITQ's |
|
|
Novice
Joined: 02 Jun 2004
Posts: 10
Location: Newyork
|
| Disable the INTQ’s ? Jefflowrey mentioned this solution on a thread posted on April 6 and after that there was some useful discussion regarding that please look at the posts at top. Yes GET inhibiting the INITQ’s will work.., But another solution you can explore is to put a shutdown message on the INTQ to stop the trigger monitor. Is that facility available on WINDOWS?? |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jun 03, 2004 6:48 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| I would have thought that the ability to recognize a 'SHUTDOWN' message wasn't platform specific as such. It would surely depend on the trigger monitor code itself. I believe that the z/OS support pack trigger monitor has been coded to accept a 0 length message as a shutdown message (We don't actually use the IBM support pack here as we have written our own). The windoze trigger monitor that I tried the GET disable on is user written too and will accept a shutdown message, but it was explicitly coded to do so. I am not sure if the 'out the box' trigger monitor accepts a shutdown message or not. I don't believe it does, but I am not 100% sure. |
|
| Back to top |
|
|
| Venku |
| Posted: Fri Jun 04, 2004 4:14 am Post subject: Shutdown message not platform specific |
|
|
Novice
Joined: 02 Jun 2004
Posts: 10
Location: Newyork
|
I see that the ability to recognize a trigger message depend on the trigger monitor code itself and it wasn’t plat form specific. On Z/OS I observed that we can shout down the trigger monitor easily by sending a shut down rather than kill the trigger monitor job itself. Thank you for sharing that information Kevin.
_________________
Venku
____________________
MQ, CICS & DB2 Consultant |
|
| Back to top |
|
|
|
|
