| Author |
Message
|
| kordi |
 Posted: Mon Apr 13, 2015 12:56 pm Post subject: Dynamic reply mechanism |
 |
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Hi,
I searched google to see how it works but I didnt find much. I would like to know how it technically works. Usually, there are two qremote, which apps are using to exchange messages.
APP1 puts messages to QR1 on QM1 and messages are transfered to QL2 on QM2, where APP2 gets them. Then APP2 process those messages and puts replies to QR2 on QM2, which delivers messages to QL1 on QM1 where APP1 collect replies.
But sometimes qremote is used by APP1 only while APP2 uses so called dynamic replies.
I understand that APP1, before putting message to QR1 sets to fields:
- ReplyToQ
- ReplyToQmgr.
Message is transmitted to QM2, where APP2 gets it from QL2, process it, and puts the reply message to.....where actually? Transmission queue with the same name as ReplyToQmgr? Or maybe there is different mechanism using dynamic queues?
Thanks in advance for your replies! |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Mon Apr 13, 2015 1:13 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Suppose on QM2 you put a message to MYREPLYQ on QM1 then all QM2 will concern itself with is how to get to QM1. What the name of the queue is is somewhat irrelevant. Assuming you have a transmission queue called QM1 or perhaps a queue manager alias then the message will make it to QM1. Once it gets there QM1 will also try to resolve MYREPLYQ on QM1. Since QM1 is 'local' it will look for a queue called MYREPLYQ.
So, basically dynamic reply queues just take advantage of the fact that MQ routing is essentially based on the Queue Manager name rather than the combination of QM and Q.
Does that make sense?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| kordi |
| Posted: Mon Apr 13, 2015 1:37 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Hi Paul,
Yes, it does make sens. However from the Java (or any other langueue) point of view, where this message is being put?
For example:
# You create MQQueueManager to connect to QM
MQQueueManager qMgr = new MQQueueManager(qManager);
int openOptions = 17;
# Then you open queue to put messages
MQQueue queue = qMgr.accessQueue(qName, openOptions);
# Then you write message to previously opened queue
MQMessage msg = new MQMessage();
msg.writeString(qmessage);
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(msg, pmo);
# Then you close opened objects and disconnect from QM
queue.close();
qMgr.disconnect();
What queue do I open when using dynamic replies? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Apr 13, 2015 2:12 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I am not sure I follow you. When you get a message request the reply to queue manager and reply to queue fields should be filled in the MQMD. So, you just open that QM/Q combination to send your reply. The actual queue where the message will be put, first hop anyway, will be a transmission queue.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| kordi |
| Posted: Tue Apr 14, 2015 12:08 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
It's maybe because of my english 
What I mean is application have to know what queue must open to put message to, correct? It can be local queue, remote queue, alias queue, transmission queueu. But this name is provided here:
MQQueue queue = qMgr.accessQueue(qName, openOptions);
When dynamic replies are cosnidered, there are not known remote queue name, where application may put replies. Application gets message from local queue, process it and then must decide where put reply. So it must know queue name to open. What object does application open when replies using dynamic reply (no qremote is involved)? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Apr 14, 2015 12:49 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Ah I'm sorry....you are now asking a Java question so I will leave it to the Java experts to answer. I tend to avoid Java whenever possible. To my mind, if a program is worth writing it is worth writing in a decent language like C 
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| kordi |
| Posted: Tue Apr 14, 2015 2:59 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Hahahaha.
Well, language doesnt matter actually. Java code is just to show what I mean I just dont understand what queue name does app uses to put message when we use dynamic reply (no qremote involved). |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Apr 14, 2015 3:26 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Well ok let's consider the MQI then.....
When you receive a message you get two fields for the reply address
| Code: |
MQMD Structure
....
MQCHAR48 ReplyToQ; /* Name of reply queue */
MQCHAR48 ReplyToQMgr; /* Name of reply queue manager */
....
|
When you want to send an answer back you copy those fields in to the MQOD that you open to send your response to.
| Code: |
MQOD Structure
....
MQCHAR48 ObjectName; /* Object name */
MQCHAR48 ObjectQMgrName; /* Object queue manager name */
....
|
It is really simple...are you looking for a complexity that isn't there?
Or I am completely misunderstanding your problem.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 14, 2015 4:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kordi wrote: |
| I just dont understand what queue name does app uses to put message when we use dynamic reply (no qremote involved). |
It literally uses the ReplyToQ ReplyToQMGR names from the MQMD as defined. In both C and Java, when the message is put, the queue manager goes through name resolution. In the scenario we're discussing here, the queue manager will observe that the reply to queue manager is not itself, lose interest in the queue name and focus on finding a transmission queue that matches the remote queue manager name. The message will be dumped into that queue to be sent to that queue manager, where name resolution will be repeated when the receiver MCA puts the message. At this point, the queue name will be matched and the message put, or the name not matched and the message sent to the dead letter queue.
Hope this helps
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 14, 2015 4:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kordi wrote: |
| I just dont understand what queue name does app uses to put message when we use dynamic reply (no qremote involved). |
You use the name of the dynamic reply queue.
What other name would you use?
As Paul says, this is in the ReplyToQueue field in the MQMD. Or, at least, ]should be. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 14, 2015 5:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you looked at all the variants of the qmgr.accessQueue method?
Have you looked at the put1 call? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kordi |
| Posted: Sat Apr 18, 2015 12:24 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Guys,
I know how it suppose to work, the theory is simple as you all explained to me. Let me explain my doubt in details:
APP1 puts message on QR1. QR1 is defined on QM1, so APP1 can open this queue for input because it exists on QM1. Message is being transmitted to QL2 on QM2, as defined in QR1.
APP2 gets message fom QL2 on QM2. It process it somehow and now wants to send it back to QM1. We assume that it replies it to QL1 on QM1 as it is defined in ReplyToQ and ReplyToQmgr of message send by APP1. APP2 opens for input queue ReplyToQ and fails, because " 2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME" on QM2.
My question is: can you show me the code how it actually works???? |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Apr 18, 2015 1:28 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kordi wrote: |
| APP2 gets message fom QL2 on QM2. It process it somehow and now wants to send it back to QM1. We assume that it replies it to QL1 on QM1 as it is defined in ReplyToQ and ReplyToQmgr of message send by APP1. APP2 opens for input queue ReplyToQ and fails, because " 2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME" on QM2. |
Wrong assumption - as has been stated many times previously, even though QL1 does not exist in QM2 a transmission queue named QM1 should, and the queue manager will drop the reply message on that transmission queue.
Try it yourself, use the RfhUtil programme to put a message in QM2 [Queue Manager Name (to connect to)], to the reply-to-queue you want it to go to [Queue Name] in QM1 [Remote Queue Manager Name (remote queues only)]; you'll see that it works.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| kordi |
| Posted: Sat Apr 18, 2015 2:21 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
| exerk wrote: |
Wrong assumption - as has been stated many times previously, even though QL1 does not exist in QM2 a transmission queue named QM1 should, and the queue manager will drop the reply message on that transmission queue.
|
This is not assumption, this is what I tested using code I wrote. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Apr 18, 2015 3:23 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kordi wrote: |
| exerk wrote: |
Wrong assumption - as has been stated many times previously, even though QL1 does not exist in QM2 a transmission queue named QM1 should, and the queue manager will drop the reply message on that transmission queue.
|
This is not assumption, this is what I tested using code I wrote. |
Then have a look HERE and see if one of the samples provided by Roger LaCroix explains it better...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
