| Author |
Message
|
| bdaoust |
 Posted: Fri May 15, 2015 10:38 am Post subject: MQ Message Getting MQRFH2 all the sudden - why? |
 |
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Hey everyone:
We have a .NET application that sends a message using the MQ Windows Client (Windows Server 2008R2, MQ Client 7.0.1.7 and .NET 4.5.1)
All the sudden, the messages landing on queue have a MQRFH2 header. This is not happening in production, just our UAT environment.
MQ admins are saying the the properties on the qmgr match up to those in production so they don't believe its an MQ config issue.
The .NET developers are saying we are using the same .NET code, same MQ client and we didn't change anything with the message bring sent, which is XML being sent as a string.
Any suggestions where I should look as to what is adding an MQRFH2 header?
While we can set the property on queue to ignore MQRH2, I'd like to find out the root cause because if whatever changed goes to production - it obviously will have a bigger impact.
Thanks,
Brian |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri May 15, 2015 10:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| are you sure it's not just an artifact of what you are using to read / view the message? |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri May 15, 2015 11:05 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
Yes, I'm positive. Because I use the same tool (MQMON) to view accross environments.
And the message with the MQRFH2 ends up crashing the consuming application.
-Brian |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 15, 2015 11:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well.
You should maybe verify the properties of the queues yourself. Look at the PROPCTL values. |
|
| Back to top |
|
|
| bdaoust |
| Posted: Fri May 15, 2015 11:26 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010
Posts: 130
|
I don't any authority in a UAT environment to look at queue properties.
I was just playing mediator between the .NET developer and the MQ admin as to what potentially changed.
We boiled it down to as something that probably can't be easily traced back of what cause the header issue.
Since we know how to ignore it, that is the route they are going. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 15, 2015 11:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The MQ admin could have changed propctl in a number of places.
the .NET developer could have changes a variety of settings to the XMS queue connection options.
The .NET developer could have changed options to WCF settings.
The .NET developer could have changed (reverted, particularly) the version of the MQ client they are using. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat May 16, 2015 6:30 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If you are still interested in tracking down the application that is doing this, accounting statistics or tracing might be helpful. For tracing, I would do something like "strmqtrc -m qmgr -t api -d all" and locate the pid.tid that put the problematic message. Usually, there is some detail in the trace on which channel did the PUT. If knowing the channel name is not good enough, there are possibly even more cryptic ways using undocumented MQ tools and native Windows tools to find the application pid that did the PUT.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
