Spring JMS MQJE001: Completion Code '2', Reason '2042' - spring

Question

My setup is Spring 3 JMS, MVC + Websphere MQ + Websphere 7
<!-- this is the Message Driven POJO (MDP) -->
<bean id="messageListener" class="com.SomeListener" />
<!-- and this is the message listener container -->
<bean id="jmsContainer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="connectionFactory" ref="xxxCF" />
<property name="destination" ref="someQueue" />
<property name="messageListener" ref="messageListener" />
</bean>
When I start up the server, the listener seems to start correctly since it receives the messages that are on the queue as I put them.
However, once I run any simple controller/action that doesn't even have anything to do with JMS it gives me the message below over and over...
DefaultMessag W org.springframework.jms.listener.DefaultMessageListenerContainer handleListenerSetupFailure Setup of JMS message listener invoker failed for destination 'queue:///ABCDEF.EFF.OUT?persistence=-1' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2042'.
DefaultMessag I org.springframework.jms.listener.DefaultMessageListenerContainer refreshConnectionUntilSuccessful Successfully refreshed JMS Connection
ConnectionEve W J2CA0206W: A connection error occurred. To help determine the problem, enable the Diagnose Connection Usage option on the Connection Factory or Data Source.
ConnectionEve A J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource JMS$XXXQCF$JMSManagedConnection#2. The exception is: javax.jms.JMSException: MQJMS2008: failed to open MQ queue ''.
ConnectionEve W J2CA0206W: A connection error occurred. To help determine the problem, enable the Diagnose Connection Usage option on the Connection Factory or Data Source.
ConnectionEve A J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource jms/XXXQCF. The exception is: javax.jms.JMSException: MQJMS2008: failed to open MQ queue ''.
The original listener seems to be still running correctly...but I think the controller is somehow triggering off another connection?
Does anyone know what I should check for or what might cause this issue?
thanks

Answer 1

The 2042 means "Object in use". Since there is no concept of exclusive use of queues for message producers, then one of your consumers is locking the queue.
This behavior is controlled by the queue definition's DEFSOPT attribute. This is at the queue manager itself and not in the managed object definitions or your factory options. From the command line while signed on as mqm (or the platform equivalent if the QMgr is on Windows, iSeries, z/OS, etc.) you would need to start runmqsc and issue the following commands to verify and then fix the problem. In my example, the QMgr is PLUTO and the example queue is SYSTEM.DEFAULT.LOCAL.QUEUE.
/home/mqm: runmqsc PLUTO
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager PLUTO.
dis q(system.default.local.queue) defsopt
1 : dis q(system.default.local.queue) defsopt
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) TYPE(QLOCAL)
DEFSOPT(EXCL)
alter ql(system.default.local.queue) defsopt(shared)
2 : alter ql(system.default.local.queue) defsopt(shared)
AMQ8008: WebSphere MQ queue changed.
dis q(system.default.local.queue) defsopt
3 : dis q(system.default.local.queue) defsopt
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) TYPE(QLOCAL)
DEFSOPT(SHARED)
If you display the queue and find that it is already set for DEFSOPT(SHARED) then something must be specifying exclusive use of the queue through the API. That typically means a C or base Java program since these non-JMS APIs have access to low-level WMQ functionality. Those can be a little trickier to diagnose and I usually use a trace or the SupportPac MA0W exit to display the API calls and options used. If this is the case, I'd want to know more about what is meant by "simple controller/action" as noted in the original post.
Finally, if the queue that you are accessing is a remote queue then it will resolve to a transmit queue. The channel will always set a transmit queue to GET(INHIBITED) and acquire an exclusive lock on it. This is consistent with WMQ functionality in that an application can only GET messages from a local queue.