| Author |
Message
|
| Slasher |
 Posted: Wed Aug 22, 2012 6:38 pm Post subject: 2093 AMQ8041 : MQRC_NOT_OPEN_FOR_PASS_ALL |
 |
|
Newbie
Joined: 07 May 2012
Posts: 5
|
A week ago i upgraded from MQ 7.0 to 7.1.0.1
These are the details of te current installation
Name: WebSphere MQ
Version: 7.1.0.1
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Windows
Mode: 32-bit
O/S: Windows Server 2008 Server Standard x64 Edition, Build 6002: SP2
InstName: Installation1
Primary: Yes
MaxCmdLevel: 710
The application is a publish / subscribe application and uses MQTT to connect to the subscribers.
The application was running fine for a week until
a. an enmqm -i command was issued while teh MQTT clients were connected , the RFHUTIL was connected and while Broker was running. I could not start the QMGR and the error was
AMQ8041 : The Queue Manager cannot be restarted or deleted because processes , that were previously connected are still running.
AMQ7018 : The Queue Manager operation cannot be completed
I resolved this by stopping Message Broker , exiting RFHUTIL , killing another instance of MQ Explorer process that was running under a different log in.
After this when the QMGR was restarted , all messgaes destined for the MQTT clients ended up in DLQ. The DLH says
2093 AMQ8041 : MQRC_NOT_OPEN_FOR_PASS_ALL
I dont see any errors in
AMQERR001.log
I dont see any FDC files
I haev performed a normal shut down of broker , and controlled shut down of MQ , rebooted the server and I still see the same issue.
You inputs will be appreciated.
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Aug 22, 2012 7:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This is quite clear:
the process opening the queue does not have the GMO/PMO options:
2093 AMQ8041 : MQRC_NOT_OPEN_FOR_PASS_ALL
You might want to look at what your program does... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 22, 2012 9:08 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Its possible that someone changed OAM authority profile(s) after the programs had previously started, and removed the authority to pass-all.
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 23, 2012 5:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Have you perhaps tripped over any of the security changes between 7.0 & 7.1?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Slasher |
| Posted: Thu Aug 23, 2012 3:49 pm Post subject: |
|
|
Newbie
Joined: 07 May 2012
Posts: 5
|
Thanks for the responses , I was able to double check the parameters you suggested , It was fine.
The error messages and behavior of the application is quite confusing.
The messages to the MQTT clients would'nt go because , a flag had to be reset.
The JBOSS server on the other end showed numerous 2059,2009 errors. I restarted the webserver to fix that.
I then could send the messages from MQTT client to JBOSS server through MQ.
However everytime I started MQ exploer , I would see the DLQ depth climb. The application was working fine , but the qdepth in DLQ was rising.
I also noticed in RFHUTIL that under the DLQ tab the row , original dest queue was showing entries of temporary queues , such as
AMQ.MQEXPLORER.1646944810
AMQ.545121257
I am not sure what their purpose is , would you have any idea?
I then emptied the DLQ , deleted the .metadata file from
users/../mqexplorer and then restarted MQEXPLORER ( strmqcfg -c ).
The problem disappeared.
Although the issue is resolved , I am unable to connect the dots here. Could you help me understand , the points I may be missing. |
|
| Back to top |
|
|
| Slasher |
| Posted: Thu Aug 23, 2012 4:12 pm Post subject: |
|
|
Newbie
Joined: 07 May 2012
Posts: 5
|
A quick update
Although the application seems to be working fine , the DLQ depth is increasing at its own pace , this time however much slow.
The destination queue name in the DLQ tab of RFH util , still shows either AMQ.**** or AMQ.EXPLOER *** |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Aug 24, 2012 12:01 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
The only time I have seen messages in the DLQ with reference to temp queues is when the temp queues have expired and a connection is trying to reconnect
Check the content of the messages on the DLQ and see the error logged there
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 24, 2012 4:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Slasher wrote: |
| ... The destination queue name in the DLQ tab of RFH util , still shows either AMQ.**** or AMQ.EXPLOER *** |
Do you literally mean that the queue name is AMQ.**** ?
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Aug 24, 2012 4:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The only thing that should be opening queues with a name like 'AMQ.MQEXPLORER' is, in fact, MQ Explorer.
As mentioned, you need to look at the DLQ Header to find out the reason code that these messages are being dumped there.
You should also probably revisit your security and ensure that you've properly blocked administrative access to your queue manager at the connectivity level.
I suspect you'll find that one of your app developers is trying to use their application svrconn to view the queue manager from a local copy of MQ Explorer. |
|
| Back to top |
|
|
|
|
