Problem(Abstract)
You notice that when the WebSphere MQ (WMQ) queue attributes of IPPROCS or OPPROCS are greater than 0, and try to end the queue manager by issuing “endmqm QmgrName”, then the queue manager goes into “quiescing” but it does not fully terminate.
Is there a way to speed up the shutdown of the queue manager?
Resolving the problem
If “endmqm QMgrName” does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:
endmqm -i QMgrName
Background:
The following page has more information about the IPPROCS and OPPROCS attributes for a queue.
Queue status attributes:
Attribute: Open input count
Meaning: This is the number of applications that are currently connected to the queue to get messages from the queue.
MQSC parameter: IPPROCS
Attribute: Open output count
Meaning: This is the number of applications that are currently connected to the queue to put messages on the queue.
MQSC parameter: OPPROCS
If “endmqm QMgrName” does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:
endmqm -i QMgrName
For more details, see the product documentation:
endmqm
The default (endmqm QMgrName) is to use “-c” as in: endmqm -c QMgrName
-c Controlled (or quiesced) shutdown :
This is the default. The queue manager stops, but only after all applications have disconnected. Any MQI calls currently being processed are completed. Control is returned to you immediately and you are not notified of when the queue manager has stopped. The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in QUIESCE mode.
>> Note: If an application has opened a queue for put or for get, but still is connected, then this will prevent the queue manager from ending. It will remain in “quiescing”.
-i Immediate shutdown:
The queue manager stops after it has completed all the MQI calls currently being processed. Any MQI requests issued after the command has been issued fail. Any incomplete units of work are rolled back when the queue manager is next started.
Control is returned after the queue manager has ended.
The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in FORCE mode.
>> Note: If a client application has opened a queue and still is connected, such as the MQ Explorer, then this option will terminate the server-client connection, allowing the queue manager to terminate.
-p Preemptive shutdown:
WARNING: !!!! Use this type of shutdown only in exceptional circumstances. For example, when a queue manager does not stop as a result of a normal endmqm command. !!!
The queue manager might stop without waiting for applications to disconnect or for MQI calls to complete. This can give unpredictable results for WebSphere MQ applications.
The shutdown mode is set to immediate shutdown. If the queue manager has not stopped after a few seconds, the shutdown mode is escalated, and all remaining queue manager processes are stopped.
The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in TERMINATE mode.
+++ Scenario
The impact that these attributes have whenever they have a value greater than Zero, when trying to terminate the queue manager is best described by a simple scenario, which is described in the rest of this technote.
A queue Q1 in the queue manager QM_VER has not been opened by any application. Thus, IPPROCS and OPPROCS are 0:
In one window enter:
$ runmqsc QM_VER
display qstatus(Q1)
2 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(0)
In another window, the MQ sample command “amqsput” is issued to put a message:
$ amqsput Q1 QM_VER
Sample AMQSPUT0 start
target queue is Q1
Notice that the text of the message has not being entered yet. The application is just waiting for the user to enter the text. The application has already opened the queue and thus, the counter for OPPROCS has been incremented from 0 to 1:
$ runmqsc QM_VER
display qstatus(Q1)
3 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(1)
In yet another window, the MQ sample command “amqsget” is issued to get a message:
$ amqsget Q1 QM_VER
Sample AMQSGET0 start
Notice that now the counter for IPPROCS has been incremented from 0 to 1, and that OPPROCS is still at 1 because amqsput is still connected:
$ runmqsc QM_VER
display qstatus(Q1)
4 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(1)
MSGAGE( ) OPPROCS(1)
But 30 seconds later, amqsget terminates because no messages arrived within 30 seconds, and now the IPPROCS counter decreased from 1 to 0. But amqsput is still connected, waiting for the user to enter a message and thus OPPROCS is still 1.
$ runmqsc QM_VER
display qstatus(Q1)
3 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(1)
Let’s assume that we wanted to terminate the queue manager, keeping in mind that amqsput is still running and connected to the queue (OPPROCS is still 1):
$ endmqm QM_VER
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete.
Notice that we cannot make new connections, not even running runmqsc:
$ runmqsc QM_VER
AMQ8156: WebSphere MQ queue manager quiescing.
$ amqsget Q1 QM_VER
Sample AMQSGET0 start
MQCONN ended with reason code 2161
$ mqrc 2161
2161 0x00000871 MQRC_Q_MGR_QUIESCING
The monitoring of the MQ processes for this queue manager do not show any changes and the processes are still running.
$ ps -ef | grep -i QM_VER
mqm 1869 1 0 13:28 ? 00:00:00 amqzxma0 -m QM_VER
mqm 1874 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzfuma -m QM_VER
mqm 1878 1869 0 13:28 ? 00:00:00 amqzmuc0 -m QM_VER
mqm 1884 1869 0 13:28 ? 00:00:00 amqzmur0 -m QM_VER
mqm 1885 1869 0 13:28 ? 00:00:00 amqzmuf0 -m QM_VER
mqm 1888 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqrrmfa -m QM_VER -t2332800 -s2592000 -p2592000 -g5184000 -c3600
mqm 1889 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzdmaa -m QM_VER
mqm 1914 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzmgr0 -m QM_VER
mqm 1928 1869 0 13:28 ? 00:00:00 amqzlaa0 -mQM_VER -fip0
rivera 2484 19416 0 13:28 pts/3 00:00:00 amqsput Q1 QM_VER
rivera 3605 19796 0 13:30 pts/4 00:00:00 grep -i QM_VER
Because an amqsput connection is preventing the queue manager from terminating, only until amqsput terminates, the queue manager will end.
One easy solution is to manually terminate amqsput, which will disconnect from the queue (OPPROCS will be 0) and the queue manager will terminate.
However, sometimes, it is not easy to identify which is the particular application that is preventing the shutdown, then it is OK to escalate the shutdown of the queue manager by issuing “-i” (for immediate).
Thus, in the same window or in another window, issue the following command, even though an “endmqm QMgrName” was issued already (but it is quiescing).
$ endmqm -i QM_VER
WebSphere MQ queue manager 'QM_VER' ending.
WebSphere MQ queue manager 'QM_VER' ended.
The “-i” flag will wait for in transit activities to terminate, but because there are none at this time, then it will terminate the connection of amqsput and then continue successfully to terminate the queue manager.
Notice that the pending amqsput is terminated with rc 2009:
$ amqsput Q1 QM_VER
Sample AMQSPUT0 start
target queue is Q1
MQCLOSE ended with reason code 2009
Sample AMQSPUT0 end
Notice that the rc 2009 means:
$ mqrc 2009
2009 0x000007d9 MQRC_CONNECTION_BROKEN
Product Alias/Synonym
WebSphere MQ WMQ
Recent Comments