Hi Paul, Hmmm. The way I read the description of the property in the Using Java manual, it appeared that the default value of the property would maintain the MQ v5.3 behavior. But in any event, in reading your note it appears that what this represents is a change in implementation that this particular application was dependent on. We cannot change the JMS specification, but the implementation of that specification (and therefore the underlying behavior) can definately change, and has often done so. Generally speaking this does not negatively effect applications that do not depend on the underlying implementation (although there are exceptions). And in this case the change in implementation does not violate either the JMS spec or the URI spec. The real problem is that the application has a defect in that it is not handling the URI correctly. In the case of the application in question (which I understand is probably not under your control) the problem really is not the fact that a change was introduced to allow one to control whether an RFH2 header is included on reply messages or not; the problem is that the the underlying implementation of this change exposed a defect in your application.
I'm not sure how to comment on your last sentence - do we really want no
changes in MQ behavior, even if those changes improve performance,
usability, availability, scalabilty, interoperability, etc, if it is
possible that the improvement delivered by that change in behavior will
expose a defect in an application? I don't know how many improvements could
realistically be made to MQ without changing its underlying implementation.
And I don't know how MQ Development can anticipate every possible defect an
application program might have. If applications intentionally (or
unintentionally, in this case) create a dependency on the underlying
implementation, this type of thing will crop up.
The real solution here is that the application should be fixed so that it
correctly handles URI strings. I know that's easy for me to say - but there
is an important reason for saying it, and that is if this JMS property is
used to in effect put a band-aid on the defective application, rather than
fixing the defect, the next change in MQ JMS that is implemented by setting
an optional parameter in the JMSReplyTo URI string will break the
application again - but next time, there may not be a JMS property
available to disable the change. I realize the application here is probably
not in your control, but you might want to push whoever owns the
application to fix this problem so they do not get stung by something like
this again in the future.
Sorry for the excess verbiage. Hopefully no offense is taken - certainly
none was intended.
Regards,
Christopher Frank - [EMAIL PROTECTED]
IBM Certified Consulting I/T Specialist
WebSphere, Americas TechWorks
Tel: 612-397-5532 (t/l 653-5532)
Mobile: 612-669-3008
Americas TechWorks Web Site
Technical Sales Support Request Form
"Meekin, Paul"
<[EMAIL PROTECTED]
.COM> To
Sent by: MQSeries MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT
List cc
<[EMAIL PROTECTED]
V.MEDUNIWIEN.AC.A Subject
T> Re: A different question about WAS
and MQ!
06/21/07 03:31 AM
Please respond to
MQSeries List
<[EMAIL PROTECTED]
V.MEDUNIWIEN.AC.A
T>
Well, there *is* a change in behaviour, although in our case it has only
served to expose a bug in the application.
Previously, unless the application specifically told it not to (or the
object read via JNDI told it not to), any reply message would contain the
RFH2 headers regardless of the original message. Now, as the manual says,
if the original message doesn't have the headers than the reply message
won't either, by default.
How does it manage to do this you might ask? As we have discovered, when
you get the original message, if it doesn't have the headers, MQ sets the
JMSReplyTo attribute to be the queue name from the ReplyToQueue field of
the MQMD. However, the JMSReplyTo queue name is specified in URI format,
i.e.
queue://QMgr/QueueName?parms (where ?parms are optional parameters)
so where with 5.3 the JMSReplyTo queue name was
"queue://MYQMGR/MY.NON.JMS.QUEUE" with V6 it has now become
"queue://MYQMGR/MY.NON.JMS.QUEUE?targClient=1" to indicate that any
messages put to this queue should not have the RFH2 headers attached.
Unfortunately the application in question determines the queue name by
reading from the 3rd slash to the end of the string rather than just
reading to the end OR a "?" if one exists. So yes, the app doesn't parse
URIs correctly.
Nevertheless, the default behaviour of MQ V6 has changed which doesn't
impress me too much, particularly as they have created an option to allow
you to control this behaviour.
Cheers,
Paul
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
Christopher Frank
Sent: 20 June 2007 22:20
To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: A different question about WAS and MQ!
Hello,
I don't believe so. My understanding is that this applies only to JMS
applications, which I assume your CICS transaction is not.
But I also don't think the default value of TARGCLIENTMATCHING
represents a change in behavior, either. From the Using Java manual:
"If an incoming message does not have an MQRFH2 header,
the Queue or Topic object derived from the JMSReplyTo
header field of the message, by default, has this flag
set so that a reply message sent to the queue or topic
also does not have an MQRFH2 header. You can switch off
this behavior of including an MQRFH2 header in a reply
message only if the original message has an MQRFH2 header
by setting the TARGCLIENTMATCHING property of the
connection factory to NO."
In other words, the previous behavior for JMS applications was to NOT
add an RFH2 header to a reply message if the coresponding request
message also did NOT have an RFH2 header. This is the default
behavior of this new property. So this is not a change in JMS/MQ
behavior, at least as far as I can see.
What is new is that, if you WANT to change this behavior (i.e. have
the reply message contain an RFH2 header even though the JMS request
message did NOT have an RFH2 header) you can do this by setting this
property to No.
At least that's my take on this. Anyone else want to chime in?
Regards,
Christopher Frank - [EMAIL PROTECTED]
IBM Certified Consulting I/T Specialist
WebSphere, Americas TechWorks
Tel: 612-397-5532 (t/l 653-5532) Mobile:
612-669-3008
Americas TechWorks Web Site
Technical Sales Support Request Form
Inactive hide details for "Coombs, Lawrence" <[EMAIL PROTECTED]>
"Coombs, Lawrence" <[EMAIL PROTECTED]>
"Coombs, Lawrence"
<[EMAIL PROTECTED]
M>
Sent by: MQSeries
List To
<[EMAIL PROTECTED]
MEDUNIWIEN.AC.AT> [EMAIL PROTECTED]
V.MEDUNIWIEN.AC.
AT
06/20/07 12:01 PM
cc
Please respond to
MQSeries List Subject
<MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT>
Re: A different
question about
WAS and MQ!
I am glad you found this because I will have the same problem when I
upgrade to WMQ 6. My JMS application sends requests to CICS. The CICS
transaction then responds and my JMS application reads the response.
Since the incoming reply message from CICS will NOT have an RFH2
header,
the derived queue destination object for the replytoQ would be set to
MQ. Well, the application that is waiting to process the message is
JMS.
Does this mean that my under WMQ 5.3 my application works, yet breaks
under WMQ 6?
Is this what happened to you?
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] On
Behalf Of Meekin, Paul
Sent: Wednesday, June 20, 2007 10:06 AM
To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT
Subject: A different question about WAS and MQ!
Hi all,
I have just discovered that I need to add a new Property to my
ConnectionFactory object which is defined within a WAS JNDI
directory.
The property is TARGCLIENTMATCHING which was introduced in MQ V6 and
which I need to turn off (the default is ON which changes the
behaviour
of MQ).
Has anyone managed to set this in WAS? Apparently it's not possible
to
do from the WAS Admin Console (I'm using 5.1.1). I've tried the
JMSAdmin
tool but once I connect to the WAS directory I can't find any of the
MQ
objects. I don't know which context to look in.
Cheers,
Paul
To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
<<inline: 21271719.gif>>
<<inline: graycol.gif>>
<<inline: pic29937.gif>>
<<inline: ecblank.gif>>
