| Author |
Message
|
| whiting |
 Posted: Wed Mar 02, 2016 9:46 am Post subject: treating message as a BLOB |
 |
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
I'm reading messages which have an RFH2 header that contains message set/format
I want to treat these messages as BLOBs, but the Reset Content Descriptor insists on having access to the message set. Is there a way to disconnect the message from a parser and access the bitstream? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Mar 02, 2016 9:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Set the input node parser to BLOB.
That should avoid the issue.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Mar 02, 2016 10:57 am Post subject: input parser |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
Thanks, I tried that.
Since the message has an RFH2 header that overrides the input parser setting.
I haven't found a way to tell the broker to ignore the RFH2. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 02, 2016 10:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Set the input node parser to BLOB.
That should avoid the issue. |
Nope - the RFH2 header trumps the node setting in IIB for an input node.
| whiting wrote: |
| I want to treat these messages as BLOBs, but the Reset Content Descriptor insists on having access to the message set |
The RCD shouldn't care about the RFH2. If it does, put a node in front of it to strip the RFH2 off.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 02, 2016 11:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
... using the BLOB domain should have ignored that, I thought.
open a PMR.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Mar 02, 2016 12:24 pm Post subject: rfh2 trumps all |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
I cleared the RFH2 (removed by setting it to NULL) in a compute node before the ResetContentDescriptor node and the RCD threw the exception "RM Dictionary not found"
Additionally I set the message format, message set and message type fields in the properties. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 02, 2016 12:32 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You would have had to clear the parts of the Properties tree as well as the MQMD/MQRFH2.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Mar 02, 2016 1:32 pm Post subject: |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
| What needs to be cleared in the MQMD? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 02, 2016 1:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| whiting wrote: |
| What needs to be cleared in the MQMD? |
Well let's be clear:
Right after the input node and before any parsing occurs (parsing set to on demand) put the content redescriptor node.
Clear the Properties fields pertaining to the message set.
The information from the message set is in the Properties folder, not in the MQMD. Don't touch the MQMD.
Make sure you check the domain on the content redescriptor node and set it to BLOB. As nothing has yet been parsed you should be good to go. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Mar 02, 2016 2:31 pm Post subject: |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
OK, I have a compute node immediately after an MQGET and I'm clearing the format, ste and type fields in the Properties. as well as deleting the RFH2 header.
The Domain on the MQGET is set to BLOB and the RCD is trying to change the domain to BLOB.
The Parse Timing is "On Demand" I'm not touching anything inside the message so no parsing should be happening.
The exception is thrown inside the RCD node.
Note: that the message set that is referredto by the RFH2 header is not available, but I shouldn't need it since I'm trying to treat this message as a BLOB.
I guess it's time for a PMR |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Mar 02, 2016 11:33 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
... using the BLOB domain should have ignored that, I thought.
open a PMR. |
I raised this very issue a nuber of years ago (at least 5) on this forum. I think MGK responded by saying that there was no way to override the RFH2 Header on an MQ Message. IT trumps the BLOB setting in the MQInput node.
So as far as I see, the product is working as designed.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| maurito |
| Posted: Thu Mar 03, 2016 12:00 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| whiting wrote: |
OK, I have a compute node immediately after an MQGET and I'm clearing the format, ste and type fields in the Properties. as well as deleting the RFH2 header.
The Domain on the MQGET is set to BLOB and the RCD is trying to change the domain to BLOB.
The Parse Timing is "On Demand" I'm not touching anything inside the message so no parsing should be happening.
The exception is thrown inside the RCD node.
Note: that the message set that is referredto by the RFH2 header is not available, but I shouldn't need it since I'm trying to treat this message as a BLOB.
I guess it's time for a PMR |
use a Reset Content Descriptor node instead of the compute node. If you clear the properties in the compute node, the RCD will not know what needs to reset.
So your flow should be:
MQGet or MQInput --> RCD --> etc |
|
| Back to top |
|
|
| timber |
| Posted: Thu Mar 03, 2016 2:31 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| I cleared the RFH2 (removed by setting it to NULL) in a compute node before the ResetContentDescriptor node and the RCD threw the exception "RM Dictionary not found" |
It would be useful to know whether this was a parsing error or a writing error. MRM does make that distinction, and a user trace would show the complete chain of errors.
Why do I ask? Because I suspect that this is what is happening:
- RCD node needs to create a message tree to propagate to the next node
- RCD node first attempts to serialize the existing message ( i.e. convert it to a bitstream ). It's already a bitstream, because it was never parsed, but...
- The MRM parser requires the message set, message type and message format in order to do anything. The RCD node supplies the information that was provided with the message ( InputRoot.Properties.MessageSet, InputRoot.Properties.MessageType, InputRoot.Properties.MessageFormat ). It fails at the first hurdle, because MessageSet is an empty string.
This is guesswork for now. A user trace would go a long way to confirming or disproving the hypothesis.
Either way, I think you have the following options:
a) Make the message set(s) available to the receiving mesage flow. May be tricky if the receiving message flow ends up requiring a large number of message sets.
b) Remove the mcd folder from the MQRFH2 header before placing it on the queue. That might involve changes to other applications.
c) Change the domain to BLOB before placing messages on the queue. That way, the receiving message flow will always use the BLOB domain to parse the message, and won't require lots of message sets. |
|
| Back to top |
|
|
| whiting |
| Posted: Thu Mar 03, 2016 3:29 am Post subject: working |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
Thanks timber.
I moved the RCD node immediately after the MQGet and the message was recast as BLOB without exception. I was thinking that I was going to have to gather all of the message sets and include them in this application.
I'll run a user trace with and without the compute node to see if that that shows, but I think my problem is resolved.
Your list of options was spot on. Those were the choices that I was wrestling with. |
|
| Back to top |
|
|
| timber |
| Posted: Thu Mar 03, 2016 6:47 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| Your list of options was spot on. |
Not really. I missed this one:
d) Do what maurito suggested, because it's the easiest and best solution.
I thought you had already tried that. |
|
| Back to top |
|
|
|
|
