| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Lookup Failure following MQ Migration 6.0.2.2 to 7.0.1.9 |
« View previous topic :: View next topic » |
| Author |
Message
|
| frankstar123 |
 Posted: Tue Dec 11, 2012 12:44 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.
Thanks for all your suggestions so far. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Dec 11, 2012 5:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
On the Queue Manager that this app is successfully connecting to, can you enable Local or Remote Events at the QM level and then inspect the event message you get in the SYSTEM.ADMIN.QMGR.EVENT queue when your app throws the 2085 MQRC?
This will tell you exactly what the QM sees from your app when it decides to throw the 2085 MQRC.
Are you trying to open a local q, Remote q, Alais q, or Clustered q defined on a QM other than the one you are connected to.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| frankstar123 |
| Posted: Wed Dec 12, 2012 3:17 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012
Posts: 15
|
OK,
I've managed to get hold of the code. The code has two methods to inquire the depth of the Queue, a JMS call and an MQ call from the java code.
The JMS method queryQueueDepthJMS
The MQ method queryQueueDepthMQ
The JMS call works but is inefficient because to find out the number of messages on the Q it will loop through them. (Must have been a decision taken a long time ago, maybe the inquire call was not availlable in JMS) A new method was written the made MQ calls, this is the method that is failing. queryQueueDepthMQ
| Code: |
private int queryQueueDepthMQ(QueueDetailsVO queueDetails)
throws QueueNotFoundException, QueueAdminException
{
// Need to connect to the MQ Queue manager and query the depth of the queue
if (logger.isDebugEnabled())
{
logger.debug("Looking up current depth of MQ queue " + queueDetails);
}
// Set the properties to be able to connect to the MQ Queue Manager
MQEnvironment.hostname = QueueProperties.getInstance().getServiceHostName();
MQEnvironment.port = QueueProperties.getInstance().getServicePort();
MQEnvironment.channel = QueueProperties.getInstance().getServiceChannel();
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
String queueName = null;
MQQueueManager mqQueueMgr = null;
MQQueue mqQueue = null;
try
{
// Find the queue name
Queue queue = lookupQueue(queueDetails.getQueueName());
queueName = queue.getQueueName();
// Connect to the MQ Queue Manager
if (logger.isDebugEnabled())
{
logger.debug("Connecting to MQ Queue Manager ");
}
mqQueueMgr = new MQQueueManager(QueueProperties.getInstance().getServiceQueueManagerName());
if (logger.isDebugEnabled())
{
logger.debug("Connected to MQ Queue Manager ");
}
// Set the queue open options, we only need inquire as we simply need the queue name and depth
int openOptions = MQC.MQOO_INQUIRE ;
// The queue can actually look itself up but has queue:/// in the front of it
if(queueName.indexOf("//")>0)
{
queueName=queueName.substring(queueName.lastIndexOf("/")+1).trim();
}
// Connect to th e MQ Queue, note that this will be the alias as the reference we are
// looking up will be the queue alias
if (logger.isDebugEnabled())
{
logger.debug("Connecting to MQ Queue for Alias");
}
mqQueue = mqQueueMgr.accessQueue(queueName, openOptions);
if (logger.isDebugEnabled())
{
logger.debug("Connected to MQ Queue for Alias, now connect to real queue");
}
//This is the alias to the queue, so we now need to find the actual queue name
int[] selectors=new int[1];
selectors[0]=MQC.MQCA_BASE_Q_NAME;//2002;
int[] intAttrs=new int[1];
byte[] charAttrs=new byte[128]; // documentation says 64, but future proof to 128
mqQueue.inquire(selectors, intAttrs, charAttrs);
String actualMqQueue=new String(charAttrs).trim();
//Now that we have the actual queue name we can connect to that and query the depth
mqQueue = mqQueueMgr.accessQueue(actualMqQueue, openOptions);
if (logger.isDebugEnabled())
{
logger.debug("Connected to MQ Queue, query current depth");
}
return mqQueue.getCurrentDepth();
}
catch (MQException mqe)
{
throw new QueueAdminException("Unable to query MQ queue depth " + queueDetails.getQueueName() +
" MQ Reason code: " + mqe.reasonCode, mqe);
}
catch (NamingException ne)
{
throw new QueueNotFoundException(ne.getMessage(),ne);
}
catch (JMSException jmse)
{
throw new QueueNotFoundException(jmse.getMessage(), jmse);
}
finally
{
if (mqQueue != null)
{
try
{
mqQueue.close();
mqQueue = null;
}
catch (MQException mqe2)
{
// Error closing MQ Queue
if ( logger.isEnabledFor(Priority.WARN))
{
logger.warn( "Error closing MQ Queue. MQ Completion Code: " + mqe2.completionCode +
", Reason Code: " + mqe2.reasonCode );
}
}
}
if (mqQueueMgr != null)
{
try
{
mqQueueMgr.disconnect();
mqQueueMgr = null;
}
catch (MQException mqe3)
{
// Error closing MQ Queue Manager
if ( logger.isEnabledFor(Priority.WARN))
{
logger.warn( "Error closing MQ Queue Manager. MQ Completion Code: " + mqe3.completionCode +
", Reason Code: " + mqe3.reasonCode );
}
}
}
}
} |
This code fails (used to work with MQ6) , when i change it back to use the JMS code it works queryQueueDepthJMS(). It can connect to the JNDI reference etc, query the queue etc, so we no the Q's exist.
So the problem is with the MQ call above we get a failure at the line after the call "Connecting to MQ Queue for Alias"
The exception is Unable to query MQ queue depth EXH01_SC1 MQ Reason code: 2085.
As I have said the EXH01_SQ is the reference name to a linked an Enterprise resource reference in the .ear file / websphere env / ejb-jar.xml, which then points to the "Target Resource JNDI Reference" , in my opinion I'm struggling to see how this worked correctly with MQ6 via a resource reference stored in WAS. I thought it should be the actual queue name. Changing code is not an option at the moment but I'd like to know how / why this works with MQ6 and doesnt in MQ7... :S |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 13, 2012 7:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well looks like this is confused all over.
How do you know in V7 that the alias refers to a queue and not a topic?
Lastly why do you need this information (qdepth)? and what are you going to do with it?
As I see it, you should be using MQ pcf format for retrieving this information, and it should be in a monitoring type of program...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| frankstar123 |
| Posted: Fri Dec 14, 2012 3:27 am Post subject: |
|
|
Novice
Joined: 10 Dec 2012
Posts: 15
|
| Quote: |
How do you know in V7 that the alias refers to a queue and not a topic?
|
Because its a queue, I know its a queue, it was a queue before and a queue after migration.
| Quote: |
Lastly why do you need this information (qdepth)? and what are you going to do with it? |
Its a scheduled task within WebShere running as a monitoring type program as you mention below. It runs within a WAS environment as a scheduled task because it inherits all the WAS stuf such as failover to 1 of 12 in a cluster, persistent state, it also inherits all of our monitoring of logs etc.
I dont think it matters what we should be doing the fact is it worked before MQ6 and now it does not work in MQ7. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 14, 2012 3:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| frankstar123 wrote: |
| I dont think it matters what we should be doing the fact is it worked before MQ6 and now it does not work in MQ7. |
Pedantically, for the benefit of other readers and probably not connected to your problem that statement is not completely correct. Any documented function of WMQv6 should work under WMQv7 unless the documentation says it doesn't. I offer as an example RFH2 handling, which changed into message properties and needs a specific setting to allow an application expecting an RFH2 to continue working.
There are also any number of things which may work in v6 due to quirks in the code which are fixed (deliberately or otherwise) in v7.
Not the case here I think (Java? What do I know?) but felt the general point needed to be made.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 14, 2012 6:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Again, use PCF messages to gather this type of information. It is more efficient (no need to access the queue) and requires fewer access priviledges (dsp + inq).
Now may be the right time to convert your application to PCF...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 14, 2012 1:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
frankstar123, did you enable those events on the QM to see what exactly the QM thinks your app is sending it when it decides to reject it with a 2085?
| fjb_saper wrote: |
Again, use PCF messages to gather this type of information. It is more efficient (no need to access the queue) and requires fewer access priviledges (dsp + inq).
|
I would argue that access to the command queue to send PCF messages is more access privilage than issuing MQINQ calls against an app queue.
Whether its PCF messages or MQINQ calls, I think we can agree its wrong for a (non monitor) app to need to use either to get the q depth. But right or wrong, an app that queried the q depth in MQ 6 should be able to do the same thing in MQ 7.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 14, 2012 8:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
I would argue that access to the command queue to send PCF messages is more access privilage than issuing MQINQ calls against an app queue.
|
Can you please explain how so? If the only priviledge you have is dsp + inq and no priviledges at class level, how can you change, delete or create anything using a pcf message? Remember you have no put priviledges (but for the command queue) so you can't float that pcf message down to a different qmgr....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
