I've known about the MQRFH2 header used by WebSphere MQ for a long time. I was also aware of the problems this header can cause when exchanging messages between JMS and non-JMS based clients, and how to suppress use of the header by using targetClient=1 (MQJMS_CLIENT_NONJMS_MQ).
What I did not know before today however, is that if a JMS application receives a message not containing the MQRFH2 header, some basic JMS message properties like JMSDestination will not be available! This makes some sense since WebSphere MQ uses the MQRFH2 header to carry JMS specific data associated with the message. If you omit MQRFH2, only the properties that fit in the default MQMD header will be transmitted, the rest will be lost. (The WebSphere MQ documentation covers this in some detail.)
Still, for something basic like JMSDestination this came as a bit of a surprise since this property is set by the JMS service provider when sending the message and you expect it to be available when receiving that message, for instance to be able to do failover processing and send the message back to its original destination at some later time.
Friday, March 5, 2010
Subscribe to:
Post Comments (Atom)
Check out the latest version of WebSphere MQ. All of the message properties are available as JMS properties now. Also, you can have a JMS and a non-JMs program both subscribing to the same topic and both successfully receive messages that were put with RFH2 headers. This has all become largely transparent in v7.0.1.
ReplyDeleteThanks for letting me know!
ReplyDeleteWe're indeed still on WebSphere MQ 6.0.
I'm currently diagnosing an issue with a high-volume application that seems to reflect that MQRFH2 format messages incur a significant performance hit on the server side at high queue depths, in contrast to MQSTR format messages. Does this sound like a familiar "gotcha" ?
ReplyDeleteWe also have quite high volume queues that use messages with MQRFH2 headers, but haven't noticed any considerable performance overhead. Having said that, we also haven't done any side by side testing to see whether or not we could gain something by using plain MQSTR headers. So at least to me the MQRFH2 overhead is not a familiar gotcha.
ReplyDeleteJust for perspective, by "high-volume" I'm referring to a queue where the volume is so high that it routinely backs up to a depth of 400,000 messages. Its at depths over 250,000 that the issue really raises its head - under that depth the performance is definitely better and less of an issue.
ReplyDelete