1

In MQ, if you have an instance of an existing queue manager, say queuemanager1 that your app has access to. You can send your message by creating a queue that points to a queue of another queue manager, queuemanager2, through queuemanager1. This is done because the app maybe doesn't have direct access to the queuemanager2 but the MQ Server hosting queumanager1 does.

The code looks something like this:

MQQueue destQueue = queuemanager1.accessQueue("queFromAnotherMngr",CMQC.MQOO_OUTPUT | CMQC.MQOO_FAIL_IF_QUIESCING,"queuemanager2", null, null);

I'm refactoring the code to use the IBM MQ JCA adapter for JBoss AS 6. So I believe I have to stick to the vanilla JMS api(Using InitialContext JNDI lookup, Producer,etc.) to have my connections managed by JBoss.

However, I can't figure out how to, in regular JMS, to allow the receiving MQ server to forward my message along to another queue of another queumanager (queuemanager2).

From what I've researched so far, there is object sent to MQ called Message queuing message descriptor (MQMD) and it has a field called "ReplyToQMgr" and "ReplyToQ". I think if I find a way to update those fields using JMS API with the JCA adpater, I have my solution. Any thoughts? Ideas? Suggestions? Solutions? Thanks!

Jack Stevens
  • 13
  • 2

1 Answers1

1

The ReplyTo fields allow the remote application to address messages back to you. They are not used by WebSphere MQ in routing the original message but are used for addressing acknowledgements and failure reports.

The way that you specify a queue on a remote QMgr using JNDI lookups is to define the QMNAME field in the queue object. Please see Properties of WebSphere MQ classes for JMS objects for a list of all the properties supported by WebSphere MQ objects. What is not mentioned in the top table is that the QMNAME property of a queue need not match the QMNAME property of the connection factory. When these properties differ, the local QMgr will attempt to resolve a path to the target QMgr when the queue object is opened. As long as it can find a path (either a transmit queue or a QMgr alias must exist with the same name as the target QMgr) and as long as your app is authorized to the transmit queue, you are good to go.

Note that if you get a JMS exception, you must inquire for the existence of and print any linked exceptions you find. These will have the WMQ reason code that will tell you or the admin whether any problems are related to name resolution, authorization or other. Please see Exceptions in WebSphere MQ classes for JMS for suggestions on how to do this. Note that this is not WMQ-specific advice. JMS specifies a multi-level structure for reporting exceptions and the linked exception is where vendor-specific errors are reported. So any JMS application, regardless of which transport provider is used, should print linked exceptions.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • So maybe creating a queue using URI by doing something like this: Queue destinationQueue = session.createQueue("queue://QMgr2/Q2") can route the message to this new queueManager/Queue(QMgr2/Q2) even though session was created from the queumanager retrieved from a jndi lookup of my original connection factory that uses the jca adapter? – Jack Stevens Mar 01 '12 at 04:07
  • I know about the need to report linked exceptions. Thanks for the input anyways. – Jack Stevens Mar 01 '12 at 04:07
  • Yes. Specifying a QMgr that you aren't connected to will cause WMQ to try to resolve the route it needs. – T.Rob Mar 01 '12 at 04:25