| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Cannot set Msd properly on JMS message. |
« View previous topic :: View next topic » |
| Author |
Message
|
| kimbert |
 Posted: Thu Sep 23, 2010 4:54 am Post subject: |
 |
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
First, let's accept that there is some uncertainty about what's going on here. Clearly ccrandall has carefully read the IBM documentation and has not managed to get the answer to his query. Since there are some things that we do *not* know yet, let's establish what we do know for certain:
| Quote: |
| The message broker parser name does not belong in the Msd field. |
That's plain wrong, I'm afraid. The mcd folder in the RFH2 has been used since WMB v2.1 to specify the message domain, set, type and format for an incoming message.
| Quote: |
| We'll see what our PMR yields. |
Yes - that's the wisest course of action at this point.
Please do as mqjeff suggests, and add a link to this thread in the PMR. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Sep 24, 2010 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Let's also not loose track of the original problem of the OP:
| Quote: |
We are migrating from MB 6.0.0.6 to MB 7.0.0.1. While migrating our broker framework, we started to get errors from Java MDBs running on WAS 7. The error we've been getting looks like:
[WMQJCAResourceAdapter : 0] 9/17/10 15:00:08:219 ERROR AbstractMessageBean - Received a com.ibm.jms.JMSBytesMessage: I do not support handling of a com.ibm.jms.JMSBytesMessage. MessageId=ID:414d512045434b3032424431202020204c8866522011b72c
When looking at the messages, we noticed that the Msd field under the Mcd folder has a different value now. Under MB 6 the value was 'jms_text' and now under MB 7 it is 'xmlnsc'. |
I take that to mean that he is getting a JMSBytesMessage where he is expecting a JMSTextMessage, hence my comment earlier in the thread that the part of the RFH2 header he should be addressing is the RFH2 format field... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ccrandall |
| Posted: Mon Sep 27, 2010 10:26 am Post subject: |
|
|
Acolyte
Joined: 23 Oct 2008
Posts: 52
|
| fjb_saper wrote: |
I take that to mean that he is getting a JMSBytesMessage where he is expecting a JMSTextMessage, hence my comment earlier in the thread that the part of the RFH2 header he should be addressing is the RFH2 format field... |
I've been meaning to reply to this for a few days, but I got hit with a contact admin cold and flu which is why my later responses had a more frustrated tone.
fjb_saper: We did set the MQRFH2.Format to MQFMT_STRING and that works. However, we have a concern that this will only disambiguate Byte from Text messages. From the blurb I found in the InfoCenter on this, I'm not sure this would help for the other JMS message types. Fortunately, we aren't using those types now, but you never know when that'll be come a requirement.
We are still moving forward with the PMR b/c I think the question as to what belongs in the Msd field has yet to be resolved. I'll be sending IBM L2 support a trace and our PIF later today and hopefully we'll get a response soon.
In the meantime, this is a summary of the things we've seen:
1.) Java MDBs in WAS 6 and 7 with MQ 6 and 7 happily accept JMSTextMessages when Msd = "jms_text".
2.) The MDBs are confused when Msd = "xmlnsc" and think the text message is a bytes message.
3.) Setting the MQRFH2.Format field to MQFMT_STRING resolves #2.
4.) We are uncertain if setting Format will help with other JMS types.
5.) Our Spring JMS publisher/sender code, using the MQ 6 and MQ 7 JMS provider sets the Msd field as "jms_text".
6.) The documentation for cmqpsc.h and the BipRfc.h header file show that the valid values for Msd are "jms_none", "jms_text", etc. Other than MRM, none of the other parser names are listed here.
7.) Much of the MQ 7 documentation is agreeing with #6.
8.) Most (all) of the MB 7 and some of the MQ 7 documentation says the parser name should be in Msd.
9.) Msd has been populated with the parser name since WMB 2.1.
10.) Looks like this is now enforced in WMB 7 (or maybe 6.1)?
So what I'm looking for now is a definitive explanation of what this field is used for and why the documentation and header files seem to disagree as to what belongs in the field... esp since the fix we have now we aren't sure will help with non-text/bytes message types.
Thanks all for the help so far! I'll update the thread when I get some info back on the PMR. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 27, 2010 11:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| 3.) Setting the MQRFH2.Format field to MQFMT_STRING resolves #2. |
It should also help with things like automatic CCSID translation.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Mon Sep 27, 2010 10:17 pm Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
urgghhh!!
Kimbert, mqjeff, fjb etc ... Correct me if Iam wrong with the below.
Wouldn't the format field we set on one header define the format of the next header in the chain all the way upto but not including the message body?
If that is true, then in the OP's case MQMD.Format is obviously MQFMT_RF_HEADER_2 which indicates that the next header is of type RFH2. The again in the RFH2 header, setting MQRFH2.Format to MQFMT_STRING would mean that the message body is to be interpreted as character data. Setting MQRFH2.Format=MQFMT_NONE(if it is not set the default is MQFMT_NONE) would mean that the body that follows is to be interpreted as a BLOB. I wonder if that is causing the JMS consumer on the java side read that as a JMS_Bytes message.
I could be totally wrong on what I said above, but I couldn't stop my itch to chime in on this. I will stand corrected if any of you could drive me in the other direction in an affably convincing manner.
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 28, 2010 2:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| paranoid221 wrote: |
urgghhh!!
Kimbert, mqjeff, fjb etc ... Correct me if Iam wrong with the below.
Wouldn't the format field we set on one header define the format of the next header in the chain all the way upto but not including the message body?
If that is true, then in the OP's case MQMD.Format is obviously MQFMT_RF_HEADER_2 which indicates that the next header is of type RFH2. The again in the RFH2 header, setting MQRFH2.Format to MQFMT_STRING would mean that the message body is to be interpreted as character data. Setting MQRFH2.Format=MQFMT_NONE(if it is not set the default is MQFMT_NONE) would mean that the body that follows is to be interpreted as a BLOB. I wonder if that is causing the JMS consumer on the java side read that as a JMS_Bytes message.
I could be totally wrong on what I said above, but I couldn't stop my itch to chime in on this. I will stand corrected if any of you could drive me in the other direction in an affably convincing manner. |
Nope, you're right. And FJ already said this?
| fjb_saper wrote: |
| The reason why you're getting a JMSBytes message instead of a JMSTextMessage is because the format on the RFH2 header is set to MQFMT_NONE, or has not been set at all. |
|
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
