Author |
Message
|
PeterPotkay |
Posted: Tue Apr 05, 2016 6:03 am Post subject: JMS setting ReplyTo - Struggling |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
An app is struggling to set the MQMD Reply To Queue populated. And I am struggling to help them. Seems straight forward, but I am not a JMS guy.
I referred them to this:
https://www.ibm.com/developerworks/community/blogs/messaging/entry/jms_request_reply_sample?lang=en
And this:
http://www.capitalware.com/mq_code_java.html
See the sample called: MQJmsSrv
Looking at their output message, the MQMD Message Type is also being set to DATAGRAM, but I think that is a symptom of them not being successful in setting the Reply To Q, as explained here.
http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032050_.htm?lang=en
Overnight they say they got their app to produce an RFH2 header and the Reply To Q value is populated in there. I want to see this later today. But I already told them their code should not be producing MQ messages with RFH2 headers, the destination application is not a JMS app and does not want RFH2 headers.
Their JNDI is held in LDAP.
I think their code is trying to set the JMSReplyTo to one of the Destination objects in the JNDI, the one that corresponds to the MQ queue that is their local Reply Q name. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Apr 05, 2016 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Whether or not you get an RHF2 - particularly on the receiving end - can be controlled with the queue properties to tell it to deliver RFH2 data as message properties.
The replytoqueue should be set in the JMS header... Unless I remember wrong...
What's amqsbcg show for the message after it's put? _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 05, 2016 6:12 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Don't know if it helps, but they say:
Quote: |
a custom app that was developed using PegaSystem's Pega7 product. Our app uses a JMS connector rule to create a message with the request queue name in the header. Our app does send ReplyToQ in the message.
However, MQ shows up the same in RFH2 header instead of MQMD header. |
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Apr 05, 2016 6:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Oh. Pega. (no, no specific experience with problems , just vague memories of working with customers using it. It seems to be a framework with lots of 'you can implement transport stuff here" connection points. )
Double check the JMS to MQ properties mappings...
And maybe FJ will be along shortly to say it has to be in the destination url rather than in a destination object... _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 05, 2016 6:39 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I want to avoid having to override their use of the RFH2 header using the MQ queue setting. That is allowing the problem and putting a band aid on it.
The log snippet they showed me yesterday had this as evidence they are setting the reply queue:
Code: |
************* Inside IF and setting reply queue name = queue:///THE.ACTUAL.MQ.REPLY.Q.NAME.HERE?persistence=2&targetClient=1 |
The code that supposedly did that is this:
Code: |
replyQueue= (javax.jms.Destination) jndi.lookup(responseQueTopic);
message.SetJMSReplyTo(replyQueue)
oLog.infoForced("************* In IF = "+replyQueue); |
That display in the log does not match exactly what their code that does the logging, hmmmm, are they even showing me the actual code???
The fact that I see targetClient=1 to me says they have the ability to toggle the presence of the RFH2 header. This code was from yesterday, where no RFH2 was produced, which matches the value of "1" for Target Client.
http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032240_.htm?lang=en
Ugh, why is this so difficult. Gotta be something stupid, one line of code or one setting somewhere.
This shows the mappings from JMS into the MQMD
http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032020_.htm?lang=en
Perhaps a clue, they are also struggling getting the Correlation ID set. I guess they are trying to do that as well for some reason, I asked why, no answer yet. But if they are having issues with Reply To Q as well as Correlation ID, interesting that both those fields are side by side in Table 1 of this link. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Apr 05, 2016 6:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
JMS won't let you set the Correlation ID?
I mean, I'm pretty sure it won't. Or the messageid. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 05, 2016 6:43 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Is there anything in the QCF or in the Destination objects in the JNDI that can control this? I don't think so, looked at all attributes 10 times, nothing looks like it woudl suppress the app's ability to set the Reply To Q.
Pega....hope this isn't some gap or bug in the vendor code.
When I look at their running MQ CLient channels, I see remote version as 000000000, which to me says they must be MQ Client 7.5.0.2, according to this: http://www-01.ibm.com/support/docview.wss?uid=swg1IC99373
The MQ server is 7.5.0.5. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 05, 2016 6:44 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
mqjeff |
Posted: Tue Apr 05, 2016 6:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
... Kind of run out of thoughts here. Too long since I've done any real things with JMS.
I would follow up on your hunch about them giving you different code, though. I mean, I know that application teams *never* make mistakes in their code and complain that it's MQ's fault... _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 05, 2016 12:32 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
https://pdn.pega.com/release-note/resolved-issues
Quote: |
ssue: 144381 SR-106916
The ReplyToQueue value in the JMS Header was not being mapped in the JMS Service request message headers field due to a flaw that caused the value to be skipped when mapping it to the clipboard. This has been corrected.
|
They don't have this fix applied.
Turns out its not even code they write, it gets generated by the app based on what fields are filled in the GUI.
https://pdn.pega.com/how-create-jms-connector
See #5 in the above link. To me that says they should be able to set any JMS header value that the JMS spec allows. Like all these:
http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032020_.htm?lang=en
But all they had access to was the Correlation ID to be set, which was working, and JMSType, where they jammed the Reply To Queue Name. Sure, it showed up in the RFH2 header, but I explained this is not correct, there has to be something wrong. Some furious Googling then found the bug I mentioned above. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Apr 05, 2016 12:51 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Apr 06, 2016 5:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Gosh. A bug in Pega.
Glad you got it fixed!
 _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
|