| Author |
Message
|
| mdeheus |
 Posted: Wed Sep 15, 2004 10:01 pm Post subject: How to NOT fill in the ReplyToQMgr |
 |
|
Newbie
Joined: 15 Sep 2004
Posts: 2
|
Hello All,
I have a problem NOT setting the ReplyToQMgr. We are setting up a MQ-Series connection between ourselves and an external party. On our side we work with Java/JMS. We are able to get the messages across but the external party claims they can not deal with the fact that the MQ field ReplyToQMgr is filled (their application crashes !!). At this moment we have no control over the external party and because they are a bit bigger than we are, we try to suit their needs and try to keep the ReplyToQMgr field empty.
The problem is this:
(also see code below)
When we use setJMSReplyTo of TextMessage we are able to set the ReplyToQ and ReplyToQMgr to anything we want. When we try to empty the ReplyToQMgr field, MQ fills in the name of our queuemanager.
On the internet I found the following remark about QueueSession.createQueue
| Quote: |
| Note that the name of the queue manager has been omitted. This is interpreted as the queue manager to which the owning QueueConnection is connected at the time when the Queue object is used. |
Does anyone know how to NOT set the ReplyToQMgr???
| Code: |
// find the queue connection factory (created using JMSAdmin)
InitialContext ictx = getInitialContext();
QueueConnectionFactory queueConnFactory = (QueueConnectionFactory) ictx.lookup(JMS_FACTORY);
// create and start the queue connection
QueueConnection queueConn = queueConnFactory.createQueueConnection();
queueConn.start();
// create the sendsession
QueueSession sendSession = queueConn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
// create the message
TextMessage jmsMsg = sendSession.createTextMessage();
// set replyTo (trying NOT to fill in ReplyToQmgr)
jmsMsg.setJMSReplyTo(sendSession.createQueue("queue:///null"));
|
|
|
| Back to top |
|
 |
| EddieA |
| Posted: Thu Sep 16, 2004 12:04 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| try to keep the ReplyToQMgr field empty |
I don't believe that this is possible. You've already seen, that if you don't fill anything in, MQ will do it for you.
| Quote: |
| their application crashes |
Get them to fix it. There's no reason that the conents of a field in the MQMD should cause this.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 16, 2004 6:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Ask them if they have a default way to route messages to your server (without using a remote queue). They might have to create a qmgr alias to avoid the crashing of their app. (See intercommunication manual)
i.e. if they have a channel MYQMGR.TO.YOURQMGR using xmitq YOURQMGR but the qmanager name you have is FOREIGN then a remote queue would enable to send messages to you using the channel.
But in order to do request reply model they would have to add following:
def qr(FOREIGN) rqmname(FOREIGN) xmitq(YOURQMGR).
Of course that means that they should not have a qmgr named FOREIGN in their network.
The other possibility would be for you to set up an alias for your qmgr to consume messages for YOURQMGR:
def qr(YOURQMGR) RQMNAME(FOREIGN)
You would need to retrieve your queue definition from JNDI:
and have for instance :
reply to queue = MYREPLYQ replyto qmgr = YOURQMGR
even though the name of your qmgr is FOREIGN.
As your counterpart has a default way of sending stuff to YOURQMGR it will get to FOREIGN and try to hop further to YOURQMGR. Then find the alias and change the qmgr to FOREIGN and finally be consumed by you as intended.
I believe there's still a lot of not talking going on there. Get the right folks together in a room and don't let them out until they fixed the problem...
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 17, 2004 5:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
but the external party claims they can not deal with the fact that the MQ field ReplyToQMgr is filled (their application crashes !!).
|
I sure would like to know exactly why. Maybe then we can figure out a way to put an alternate value in there.
But Eddie is correct. They need to fix that. That's just plain silly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 17, 2004 2:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Also, try playing around with ReplyTo Aliases, detailed in the Intercommunication Manual. I have used them in the past when an app connected to QMA needs to specify the reply to info as ReplyQueueA / QMX. I define a reply queue alias valled ReplyQueueA.Alias that has the RNAME as ReplyQueueA and RQMNAME as QMX. When the app sets the Reply To Queue, it specifies ReplyQueueA.Alias. The message leaves QMA with ReplyQueueA / QMX in the MQMD. It might work for you if you specify " " for the RQMNAME in the alaias. Not sure if the local QM will again try and stick its name in the MQMD.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Sep 17, 2004 3:35 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| They need to fix that |
Absolutely. You don't want to compound the issue by implementing "work-arounds".
And if they won't, I would then ask them how they tested the application in house. Even messages that don't traverse QM to QM still have the Reply to QM filled in. Or are the apps written under the assumption: Well, we wrote it, therefore it must work. Which obviously, they don't.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 18, 2004 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If they have a remote queue setup for this purpose and you have no dynamic reply to queues, maybe the qmgr and reply to queue you need to set onto your message is their remote queue and their qmgr.
This way there should be no problem with being unable to find a default way. We used it this way when there was no default way from qmgr A to qmgr B but there was a channel an xmitq and a remote queue pointing to our local queue.
Enjoy |
|
| Back to top |
|
|
| EddieA |
| Posted: Sat Sep 18, 2004 1:08 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
People. Why all the suggestions about how to route messages back. This was not the problem.
Admittedly, not having the Reply-to QM filled in would make it more of a manual set-up to get the reply. If they are actually needing one.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 18, 2004 1:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| On our side we work with Java/JMS |
This means that the reply to qmgr is allways filled in if you set a reply to queue(JMSDestination). If your reply to qmgr is blank then the JMS implementation just fills in the current qmgr.
Now if the qmgr servicing the request has a problem with that it just means that there is no default way to route messages from the servicing qmgr to the requesting qmgr. Ususally a qmgr alias would do the trick. A qmgr naming conflict (name already exists in the servicings qmgr network) will prevent you from doing this.
Barring the qmgr alias because of naming conflicts, specifying a remote queue with the qmgr filled in as the servicing qmgr that finally points to your local queue should give you the same results providing that you do not use dynamic queues. Jndi setup and lookup should take care of that.
Now if you do use dynamic queues, specifying a fictionnal qmgr name will get you around the naming conflict but will require an Alias on either of the requesting/ servicing qmgr or on both. You will probably need programming to take care of this scenario.(cast your dynamic reply to queue to MQQueue and change the qmgr name on it) before setting it as a JMSDestination on your message. First try creating a model queue with the fictionnal qmgr name in jndi. It might just work if you have an alias to make your qmgr consume messages for the fictionnal qmgr.(no garantee...) 
Last but not least, if you are not in a request/ reply to scenario, just don't set the reply to queue on the message.
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Sep 18, 2004 3:14 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
If they have a remote queue setup for this purpose and you have no dynamic reply to queues, maybe the qmgr and reply to queue you need to set onto your message is their remote queue and their qmgr.
|
Yes, this would work, but the original problem as stated was they can't have anything in the Reply2QM, apparently not even their QM (who wrote this thing, and like Eddie said did they test it?)
mdeheus needs to give us the details of what their app is really doing with that field, and why it is bombing. Still not clear if he wants both the Reply2Q and Reply2QM blank, or just the Reply2QM. What if you simply filled in 48 blanks into the field, as recommended from the below quote from the App Prog Ref Manual:
| Quote: |
If a reply-to queue is not required, it is recommended (although this is not
checked) that the ReplyToQMgr field should be set to blanks, or (in the C
programming language) to the null string, or to one or more blanks followed by a
null character; the field should not be left uninitialized.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 19, 2004 8:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
One reason for this if there is a need for a reply to queue, is the fact that I suspect that they already have a default routing to the reply to qmgr but it is for a qmgr in their own network, not for a qmgr in the requester's network. Thus they can't accept the qmgr name of the requester...
Blanking out the qmgr would ensure that the reply to message goes to the remote queue (same name as reply to queue) on the servicing qmgr and gets routed correctly to the requesting qmgr.
Now having the servicing qmgr name there should work. But maybe they are unwilling to disclose that name to the requesting organization, or they are using load balancing which means that they have multiple qmgrs acting as servicing qmgrs in which case the qmgr field would need to be blank (should not be a known qmgr as this would funnel everything through a single point of failure qmgr). blank replyto qmgr -- not an option in JMS --.
In such a scenario, running and testing with a blank qmgr would work in the servicing organization. So would setting a specific qmgr in the servicing org but this would come back to single point of failure qmgr...(may not be acceptable as per servicing contract)
The alternative create a default routing for a qmgr that is just a place name holder and have communication set up with aliases. This would allow as well multihop routing. The requesting qmgr must then have an alias that allows him to consume the messages for the place holder name.
Setup see my previous post. |
|
| Back to top |
|
|
| mdeheus |
| Posted: Mon Sep 20, 2004 11:35 pm Post subject: thanks for all the input |
|
|
Newbie
Joined: 15 Sep 2004
Posts: 2
|
Hallo All,
Thanks for all the input !!
Your reactions helped me convince my managers that our "other party" is not 100% on top of things.
I told the external party we were not able to empty out the ReplyToQMgr field. This caused them to look at the problem further en since then we moved a bit further. It appears that their application doesn't crash but just has problems finding the QueueManager to which the reply should go (obviously because the name of out QueueManager is filled in and that one is not defined on their side).
This was not a technical problem but more a lack of knowlegde problem on the other side.
thanks a again for the input. Your reactions made the difference... |
|
| Back to top |
|
|
|
|
