| Author |
Message
|
| sathyapbe |
 Posted: Mon Apr 16, 2018 8:18 am Post subject: C# to IBM MQ-Remove the MQHRF2 from the requests |
 |
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
Hi,
I am new to C# to IBM web sphere MQ integration. The very first request to MQ doesn't have the additional headers but the subsequent requests has the additional headers. We are using external MQ so we don't have any control to change the option there. Any one of you can please help me to get rid of the additional headers from the subsequent requests.
amqmdnet.dll version 8.0.0.4
Thanks in advance! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Apr 16, 2018 9:45 am Post subject: Re: C# to IBM MQ-Remove the MQHRF2 from the requests |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
| We are using external MQ so we don't have any control to change the option there. |
External to your application? External to your organization?
| sathyapbe wrote: |
| Any one of you can please help me to get rid of the additional headers from the subsequent requests. |
Have you posted this in the Message Broker section because there's a message broker somewhere in your topology, because you think MB & MQ are the same product or because you didn't read the section headings before posting? It's important because MB uses RFH2 for some functions.
Why do you need to remove them? Why not just ignore them if they contain no information that you need? What problem are they causing?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sathyapbe |
| Posted: Mon Apr 16, 2018 10:01 am Post subject: |
|
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
Thanks for the reply!
External to my application.
Sorry for the confusion. My query is related to MQ.
Due to this additional headers the end host service is not processing the requests so the transactions are getting failed. I have to send the requests without additional headers. Please let me know if you want more details. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 16, 2018 10:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
| External to my application. |
So you could request on-site admins to change queue manager and/or queue properties if required.
| sathyapbe wrote: |
| Due to this additional headers the end host service is not processing the requests so the transactions are getting failed. I have to send the requests without additional headers. |
If you were using JMS, you'd use a property called TARGCLIENT to indicate the receiver wasn't JMS and the extra JMS properties (the contents of the RFH2) should not be transmitted. As you're using XMS I've no idea what the equivalent is; a C# developer will be along in a minute I'm sure.
In the meantime, look for a method on the queue object you're using in your code to put the message that talks about target type, message type or something of that nature. Experiment with various values, especially anything that calls itself "Native", "MQ", IBM MQ" or "Not JMS".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 16, 2018 10:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
| Sorry for the confusion. My query is related to MQ. |
Moving to more relevant section.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sathyapbe |
| Posted: Mon Apr 16, 2018 10:50 am Post subject: |
|
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
I have been searching the similar property JMS TARGCLIENT in C# from the day1 but no luck.
One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.
Checked the windows servers OS, IIS and configurations. It seems all are similar. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 16, 2018 10:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.
Checked the windows servers OS, IIS and configurations. It seems all are similar. |
Have the MQ admins checked that the queue managers in question have the same compatibility settings? One may be set to hold attributes as properties (modern behavior), one may be set to hold attributes as RFH2 headers (old behavior, retained even in MQv8 for backwards compatibility)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 16, 2018 7:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| sathyapbe wrote: |
I have been searching the similar property JMS TARGCLIENT in C# from the day1 but no luck.
One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.
Checked the windows servers OS, IIS and configurations. It seems all are similar. |
Look for the targetClient property on the Destination. It can also be set dynamically by the destination URI:
| Code: |
qname="queue:///MY.QUEUE?targetClient=1";
MQQueue = (MQQueue) session.createQueue(qname); |
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sathyapbe |
| Posted: Mon Apr 16, 2018 10:09 pm Post subject: |
|
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
Vitor,
I think we almost reached the issue root cause. Thank you!
I have CAT windows server and PROD windows server with the similar configurations and the same C# API build. Both are sending the request to the same IBM MQ. CAT server requests doesn't have additional headers but PROD server subsequent requests has the additional headers.
While reach out to MQ admin, how can I ask the question to check the "set to hold attributes". In the queue manager, do we have settings for each client servers with server name?
fjb_saper,
I am getting the below error while changing the queue name as per your advise. Please correct me if I am wrong.
Error trying to open Request Queue for writing. Error[2085]
Code:
_requestQueueName = "queue:///XXX.REQUESTS?targetClient=1";
private MQQueue _requestQueue;
_requestQueue = _mqQMgr.AccessQueue(_requestQueueName,
MQC.MQOO_OUTPUT // open queue for output
+ MQC.MQOO_FAIL_IF_QUIESCING); |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 17, 2018 2:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
so you get 2085 error which means the queue does not exist on the queue manager you are connected to. Try "queue://QMGRNAME/QNAME?targetClient=1" or if cluster replace QMGRNAME with cluster alias name...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 17, 2018 5:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
| While reach out to MQ admin, how can I ask the question to check the "set to hold attributes". In the queue manager, do we have settings for each client servers with server name? |
Both channels and queues have a PROPCTL attribute that controls the handling of an RFH2 header.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sathyapbe |
| Posted: Tue Apr 17, 2018 6:28 am Post subject: |
|
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
Vitor,
Both CAT and PROD servers are sending the requests to the same IBM MQ, same Queue Manager, channel, request queue and response queue but how come the attribute is varying for the different client. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 17, 2018 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sathyapbe wrote: |
| Both CAT and PROD servers are sending the requests to the same IBM MQ, same Queue Manager, channel, request queue and response queue but how come the attribute is varying for the different client. |
Do CAT & PROD host queue managers, or are both servers hosting examples of this application clienting to a single queue manager?
If so, why are (what sounds like) Prod and non-Prod messages going to the same queue?
Explain your topology. Carefully.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Apr 17, 2018 9:16 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
sathyapbe, ignore everything related to JMS as it is a red herring unless you are using XMS with C#.
Is the target (destination) queue in the SAME queue manager as that which you are connecting to?
i.e. If you C# .NET application is connecting to queue manager 'MQA1', is the target queue (i.e. 'ABC.Q') in MQA1 or does the message hope to another queue manager i.e. MQB1.
Topology:
C# .NET app ---> MQA1 with queue 'ABC.Q'
or is it
C# .NET app ---> MQA1 <---> MQB1 with queue 'ABC.Q'
i.e. Is there a XMIT involved?
You need to compare the PROPCTL of your target queue and XMIT (if one is used) between your CAT and PROD environments.
i.e. CAT
DIS Q(ABC.Q) PROPCTL
DIS Q(MQB1.XMIT) PROPCTL
i.e. PROD
DIS Q(ABC.Q) PROPCTL
DIS Q(MQB1.XMIT) PROPCTL
Most likely one of them is NOT set to 'COMPAT'.
Of course, this is assuming you are actually running the same code in both environments.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| sathyapbe |
| Posted: Tue Apr 17, 2018 9:21 am Post subject: |
|
|
Novice
Joined: 16 Apr 2018
Posts: 21
|
Due to lack of test accounts we haven't used CAT IBM MQ server.
While doing the testing we were using our windows CAT server and pointed to PROD IBM MQ. It was working as expected.
We rolled out the application to our windows PROD server and pointed to PROD IBM MQ. It is not working as expected because of the additional headers. |
|
| Back to top |
|
|
|
|
