Author |
Message
|
frankstar123 |
Posted: Mon Dec 10, 2012 8:18 am Post subject: MQ Lookup Failure following MQ Migration 6.0.2.2 to 7.0.1.9 |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
Hi Guys,
I have a problem and my feeling is that its a WebSphere application server problem, however we have managed to fix the problem my restoring MQ back to 6.0.2.2.
What we have done;
We have migrated our Q Managers + Q from 6.0.2.2 -> 7.0.1.9, we can put get etc on these queues via MQ calls. The Q Mgrs start up without issue. We got messages stating that it was migrating from 6 -> 7 on first start up.
The problem.
Our Applications get a "Unable to query MQ queue depth EXH01_SC1 MQ Reason Code: 2085"
These applications are .ears running under WebSphere 6.1.0.29.
The Q reference EXH01_SC1 is created under WebSphere -> Enterprise Applications -> APP_NAME -> Resource Reference.
The EXH01_SC1 points to a target resource jms/q/A_Q_NAME.
The Target resource then points to the "Queue" with the JNDI name jms/q/A_Q_NAME which then has a Base Q Name <BASE_Q_NAME> which is the name of the Q in IBM MQ.
So there is a bit of abstraction in the we call the JMS Qs via the Resource Reference.
However if we revert back to MQ 6 our application works. As part of the Migration we have not touched WAS directly. The MQ_INSTALL_ROOT is set to /opt/mqm where MQ 6 and 7 are installed (not together we only have 1 version installed at any other time)
Does anyone have any idea? Unfortunately we do not have code access / developer access so we cant call the Queue directly.
Does any one have any suggestions to what to check? We have created brand new Qmgrs (to rule out "migrated QMgrs") We have created new Queues and pointed the Resource Reference to the new Queues and still get the same exception.
Have we missed a step in our migration.... :S
Thanks in advance.
Frank |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 10, 2012 8:32 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
frankstar123 |
Posted: Mon Dec 10, 2012 8:37 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
The object exists and has always existed.
Can you clarify what you mean? We can put MSGs and Get msgs from the Q in V6 and V7. The problem is the call from Java code. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 10, 2012 8:40 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
frankstar123 wrote: |
The object exists and has always existed.
Can you clarify what you mean? We can put MSGs and Get msgs from the Q in V6 and V7. The problem is the call from Java code. |
From the viewpoint of your code, the object does not exist. Thats what 2085 RC means.
Only you can prevent forest fires. Use the debugger to step through your code and examine the QMGR name and the Queue Name just before your code calls MQOPEN. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
frankstar123 |
Posted: Mon Dec 10, 2012 8:44 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
We have done this, we can see the name, we can see the JNDI ref, these work in MQ 6 but after migration they do not work. The objects are there. Nothing has changed except the MQ Client and Server.
To put this in perspective we have done this on 3 SYSTEM Test Environments, and 1 UAT environment and all 4 environments fail with the same exception.
All 4 environments worked before migration to MQ 7 and work after restoring back to MQ6. No code change has been made. No Queues are dropped / recreated the same objects exist before and after the deployment.
Are we missing a WAS step ? |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 10, 2012 8:49 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
Vitor |
Posted: Mon Dec 10, 2012 9:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
They are much different. |
Unlike those 2 links, which appear to resolve to the same place....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
frankstar123 |
Posted: Mon Dec 10, 2012 9:11 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
Thanks, I am pretty sure; however I'm checking the following;
1) If everything has been cleanly shutdown and restarted (ND, Nodes etc)
2) Any applications have their own *mq*.jar files.
I'll get back to you.
Thanks for your persistence  |
|
Back to top |
|
 |
frankstar123 |
Posted: Mon Dec 10, 2012 10:01 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
I have removed all jar files from ~/AppServer/lib/WMQ/java/lib (which were 6)
Restarted the DM, Node and Application Server. The application still fails with the same exception and does not complain about missing MQ jar files. I presume the the MQ_INSTALL_ROOT variable loads the MQ jar files/
Classpath/Working dir do not point any MQ references...
There are no MQ jar files in the application.....
I'm running out of ideas. NExt i'll remove that GLOBAL MQ_INSTALL_DIR variable to prove that we are actually using it, and its the variable that gives me "access" to mq jars. |
|
Back to top |
|
 |
frankstar123 |
Posted: Mon Dec 10, 2012 10:16 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
I've removed MQ_INSTALL_ROOT and the application fails with NoClassDefFoundException.
So its been using MQ 7 binaries / jars from the start. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 10, 2012 10:18 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 10, 2012 10:20 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
You can also open a PMR to get troubleshooting help. Essentially the jms jndi reference resolves to an unknown object.
If you say that the objects exist, then the logical conclusion is the resolved reference is incorrect. So you should debug the jndi resolution of the string you are passing to jndi. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
zpat |
Posted: Mon Dec 10, 2012 11:37 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Make sure you are on the version of WAS 6 that supports WMQ v7. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Dec 10, 2012 9:47 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
frankstar123 wrote: |
We have done this, we can see the name, we can see the JNDI ref, these work in MQ 6 but after migration they do not work. The objects are there. Nothing has changed except the MQ Client and Server.
|
How are you inquiring the queue depth? By putting a pcf message on the queue? If yes how are you getting the qmgr info for the pcf client?
My guess is that the PCF client is connecting to some default qmgr that does not have the queue... You should avoid using a default qmgr if you can.
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
frankstar123 |
Posted: Tue Dec 11, 2012 12:02 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012 Posts: 15
|
Hi Thanks for the suggestions.
PMR Raised on the 6th decemeber no progress really, suggesting upgrading to last patch etc, which has been done.
MQ = 7.0.1.9,
WAS = 6.1.0.29 which i believe is supported. (IBM have not suggested to upgrade, we have an EOL project for WAS6.1 so we dont want to patch unless we have to.
Regarding JNDI lookup, if i change the name in the properties file from: java:comp/env/EXH01_SC1 to java:comp/env/EXH01_SC1111 i get a lookup failure.
Its almost like the Resource References in the EAR dont link to the JMS Queues, but they have not changed. We can revert back to MQ6 and it works. We dont touch WAS, we are obviously missing a migration step.
I'll upload the code when I get a chance to "null-a-fy" it. |
|
Back to top |
|
 |
|