| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| resolvedQueueManagerName.... |
« View previous topic :: View next topic » |
| Author |
Message
|
| MichaelR |
 Posted: Wed Nov 26, 2003 8:26 am Post subject: resolvedQueueManagerName.... |
 |
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Anybody ever report problems with Java Client dynamically "resolving" remote queue and queue manager names?
Have situation where Java Client (Win2k, 5.3, CSD05) writes message to local queue. Client application constructs MQMD with Reply-to-queue name of "locally" defined remoteQ definition. However, when message arrives and is viewed on Queue, MQMD contains reply-to-queue & reply-to-queue-Mgr names "retrieved" from RemoteQ definition!
Trace of Client session reflects RemoteQ definition values supplied in MQMD. This is indicated in both sent & received client segments.
As this is only happening with the Java Client, is this an undocumented bonus feature or bug?
Thanks in advance for your feedback!
MichaelR
 |
|
| Back to top |
|
 |
| leongor |
| Posted: Thu Nov 27, 2003 2:43 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
You just used what is called "Reply-to Queue Alias".
It should work exactly as you described without any relation to java.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| MichaelR |
| Posted: Fri Nov 28, 2003 8:21 am Post subject: |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Reply-to-queue alias? Interesting feature...
Problem is, the name of the "locally" defined reply-to-queue is specified in the MQMD of the request message. My question is, when using Java, why is the Reply-to-queue and reply-to-queue-manager values, as passed in the MQMD, being replaced with the values from the locally defined RemoteQ?
Note that this ONLY happens when using java. I have performed identical tests using MQI & ActiveX, each providing "traditional" results.
You should also know that, if I remove the QMgr value in the locally defined RemoteQ def, Java populates the MQMD with the blanks.
Fact is, when using java client, value supplied in MQMD for Reply-to-Queue is being "replaced" with values from local definition. This behavior is not consistent when using C, VB, Cobol, etc...
Mind you, though, if developers correctly construct the MQOD to include both the Reply-to-queue AND Reply-to-Q-Mgr, this isn't an "issue". Problem is, they tend to expect a local definition of a RemoteQ, thus they fail to provide the QMgr name at MQOPEN time. While I know this is a truely bad practice, the question/issue remains, is this behavior a "hidden feature" of the Java client? If so, why empower java to perform object name resolution differently.
Appreciate your feedback. Your point of alias' is well taken, however, I would expect such behavior if I were using alias definitions. Unfortunately I'm not.
Sincerely,
MichaelR
 |
|
| Back to top |
|
|
| leongor |
| Posted: Sun Nov 30, 2003 10:15 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Maybe I don't understand you correctly, but I tried to put request message to local queue
with replyq as remote queue ( locally defined ) and replyQM empty.
Everything works fine. I can see that replyQ and replyQM are replaced from remote queue definition.
I used java put utility ( ma0j support pack) and rfhutil ( ih03 support pack ).
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| MichaelR |
| Posted: Mon Dec 01, 2003 7:15 am Post subject: |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Your results are precisely what I experienced.
While this works as described, it is confusing and, potentially, problematic. If, in the example, you remove the Remote Qmgr name in the local definition, you'll find that the Reply-to-QMgr value in the incoming messages MQMD is "blank". This will surely create a problem at MQOPEN time. Of course this could be avoided by defining an Alias, but that kinda defeats the purpose of the QRemote definition.
Good programming and admin aside, this behavior is inconsistent with other MQ application interfaces and contradicts MQ object name resolution.
As you've been able to successfully duplicate my findings, I'll assume this behavior is either by design or accident. Now to get IBM's feedback on this.
Appreciate your time and assistance!!!
Respectfully,
MichaelR
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
