JMS MQ binding problem

I have this strange issue with a JMS binding on a MQ queue with a MDB

The Message-Driven EJB: CrbEventMessageAsynchronousS开发者_运维问答ervice is unable to connect to the JMS destination: queue.contratto.crb.input.publicQueue. The Error was:

javax.jms.JMSException: MQJMS1017: non-local MQ queue not valid for receiving or browsing>

I checked on the QueueManager and the mq queue is defined as local and not as remote as said by the exception.

---

It may be that the top-most queue that the application is opening for reading is defined locally. However, the queue that WMQ is resolving to is not. For example, if you define a local alias over a remote clustered queue, the resolved queue is non-local. Another possible cause is that a queue you intend to open for output is actually being opened for input as well. This is actually quite common.

Finally, it is also somewhat common that the WMQ client is connected to a different queue manager than expected. For example, the connection is to QMGRA and the queue object specifies a fully-qualified name like QUEUE@QMGRB. Even though the queue lives on QMGRB and the JNDI object specifies that queue manager by name, the connection on QMGRA resolves it to a transmit queue and therefore sees it as non-local.

One of the best ways to nail this kind of error down in Dev is to use SupportPac MA0W. This SupportPac runs as an API exit or as a channel exit and lists in human-readable language all of the API calls and all of the options selected for the call. This will unequivocally show exactly what object name was opened, what it resolved to and the options used.

Alternatively, you can turn on trace using strmqtrc. Don't forget to disable it with endmqtrc when you are done! These traces are enabled and disabled on the QMgr server and trace WMQ API calls. There are equivalent traces to run on the client side but these may not show the level of detail that you require.

Finally, it would be advisable to print any exceptions linked to the JMS exceptions. The JMS Exception is a multi-level data structure where the linked exception holds provider-specific values. For example, a JMS Security exception might be a WMQ authorization error. But then again, it might be an error in the keystore or filesystem. If the linked exception does not show a WMQ 2035 reason code, it's not a WMQ security error. The Infocenter describes how to print the linked exception data in the section named Exceptions in WebSphere MQ classes for JMS.

Note that I've provided links to the v7.0 WMQ docs. If you are coding in v6 these may not be completely accurate and you would want to look in the v6.0 Infocenter instead. Since v6.0 of WMQ is end-of-life as of September 2011 it is highly recommended to do all new development on v7.0. If you need the v7.0 client it is downloadable as SupportPac MQC7 and is backward compatible with v6.0 WMQ servers.