| Author |
Message
|
| jayZ |
 Posted: Fri Mar 15, 2013 6:52 am Post subject: Internal error codes are '1511' and '2' |
 |
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
While attempting to deserialize an xml string in a compute node, I received an error that contained the above text. Assuming there was some simple message formatting issue, I looked at the string I was attempted to convert, but found nothing wrong with it (the message was quite long). Once that effort failed, I tried to search the infocenter for the 1511 error code, but found nothing.
Would anyone here know what that code means or where I could find out?
I'm not asking anyone to solve this for me, but just looking for help to understand the error. However, here is the rest of the text from the trace file:
| Code: |
Mar 12 14:26:51 t-corp-intbk-01 user:err|error WebSphere Broker v7003[12976292]: (CARBRKT01.EG_ADESA_02)[6684]BIP2230E: Error detected whilst processing a message in node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans'. : CARBRKT01.0ab54871-3101-0000-0080-c2286b38312c: /build/S700_P/src/DataFlowEngine/ImbComputeNode.cpp: 489: ImbComputeNode::evaluate: ComIbmComputeNode: com/adesa/trans/customer/MF_TRANS_CUSTOMER_SOAPJMS#FCMComposite_1_9.com/adesa/trans/customer/MSF_TRANS_CUSTOMER_PROCESS_OB#FCMComposite_1_30.com/adesa/trans/customer/toyota/MSF_TRANS_CUSTOMER_OUTBOUND_TOYOTA_DLRE#FCMComposite_1_5
Mar 12 14:26:51 t-corp-intbk-01 user:err|error WebSphere Broker v7003[12976292]: (CARBRKT01.EG_ADESA_02)[6684]BIP2488E: (com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main, 36.6) Error detected whilst executing the SQL statement 'DECLARE refInData REFERENCE TO xmlData.XMLNSC.VFPData;'. : CARBRKT01.0ab54871-3101-0000-0080-c2286b38312c: /build/S700_P/src/DataFlowEngine/ImbRdl/ImbRdlStatementGroup.cpp: 641: SqlStatementGroup::execute: ComIbmComputeNode: com/adesa/trans/customer/MF_TRANS_CUSTOMER_SOAPJMS#FCMComposite_1_9.com/adesa/trans/customer/MSF_TRANS_CUSTOMER_PROCESS_OB#FCMComposite_1_30.com/adesa/trans/customer/toyota/MSF_TRANS_CUSTOMER_OUTBOUND_TOYOTA_DLRE#FCMComposite_1_5
Mar 12 14:26:51 t-corp-intbk-01 user:err|error WebSphere Broker v7003[12976292]: (CARBRKT01.EG_ADESA_02)[6684]BIP2498E: (com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main, 36.37) : An error occurred when navigating to path element '3' of the field reference at the given location. : CARBRKT01.0ab54871-3101-0000-0080-c2286b38312c: /build/S700_P/src/DataFlowEngine/ImbRdl/ImbRdlFieldRef.cpp: 1910: SqlFieldReference::navigateAbsoluteToFirst: ComIbmComputeNode: com/adesa/trans/customer/MF_TRANS_CUSTOMER_SOAPJMS#FCMComposite_1_9.com/adesa/trans/customer/MSF_TRANS_CUSTOMER_PROCESS_OB#FCMComposite_1_30.com/adesa/trans/customer/toyota/MSF_TRANS_CUSTOMER_OUTBOUND_TOYOTA_DLRE#FCMComposite_1_5
Mar 12 14:26:51 t-corp-intbk-01 user:err|error WebSphere Broker v7003[12976292]: (CARBRKT01.EG_ADESA_02)[6684]BIP5009E: XML Parsing Errors have occurred. : CARBRKT01.0ab54871-3101-0000-0080-c2286b38312c: /build/S700_P/src/MTI/MTIforBroker/GenXmlParser4/ImbXMLNSCParser.cpp: 893: ImbXMLNSCParser::parseFirstChild: :
Mar 12 14:26:51 t-corp-intbk-01 user:err|error WebSphere Broker v7003[12976292]: (CARBRKT01.EG_ADESA_02)[6684]BIP5004E: An XML parsing error 'The markup in the document preceding the root element must be well-formed.' occurred on line 1 column 3 when parsing element '/Root/XMLNSC'. Internal error codes are '1511' and '2'. : CARBRKT01.0ab54871-3101-0000-0080-c2286b38312c: /build/S700_P/src/MTI/MTIforBroker/GenXmlParser4/ImbXMLNSCDocHandler.cpp: 634: ImbXMLNSCDocHandler::handleParseErrors: ComIbmSOAPInputNode: com/adesa/trans/customer/MF_TRANS_CUSTOMER_SOAPJMS#FCMComposite_1_1 |
|
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Fri Mar 15, 2013 7:02 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Quote: |
| 'The markup in the document preceding the root element must be well-formed.' |
This happened to me once when I received an XML document with white space (CR/LF/TAB) at the end of the opening stanza.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jayZ |
| Posted: Fri Mar 15, 2013 7:32 am Post subject: |
|
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
| That is exactly what I thought, too. In fact, the XML (too large to edit, too sensitive to post) does have some formatting in it (CR/LF). Weird thing is, the client application logs a copy of that message and when I manually process the message using that copy it works. Even when I keep all of the original formatting and content, it processes fine. That's why I am so reliant on the meaning of those codes. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 15, 2013 7:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
jayZ: You appear to be using service trace for a simple diagnostic task. Any reason why you didn't do one of the following:
- Look for errors in the system event log for errors ( Linux )
- Look for errrors in the Application log in Event Viewer ( Windows )
- Take a user trace.
The key point is this: service trace is not meant for users. User trace is. And user trace is roughly 20 times smaller and far easier to read. |
|
| Back to top |
|
|
| jayZ |
| Posted: Fri Mar 15, 2013 9:52 am Post subject: |
|
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
| I'm almost positive the logging is at the user trace level. Our admins control the normal outage levels (as well as all access to server logs, even in dev) and we must specifically request for service traces to be turned on, which I have not done here. Just as an aside, the service trace files I've seen are much more ugly than even that. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 15, 2013 10:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jayZ wrote: |
| I'm almost positive the logging is at the user trace level. |
I've got to say that doesn't look like a WMB user trace to me. Certainly not what I get when I take a trace.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 15, 2013 11:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should review the APARS that are fixed in 7.0.0.5 just to make sure you're not trying to troubleshoot a known issue in 7.0.0.3.
You should never expect to get any information about anything labeled "internal error code" through any means except a PMR, and even likely not then.
You should confirm that the message data is actually in the codepage specified in the xml declaration. It's entirely likely that the sending application has sent an xml file in Windows formatted non-Unicode characters and labeled it as being "utf-8".
You should confirm that you have an accurate bitstream representation of the message presented from the application. The fact that you can "reprocess it" and it works fine strongly suggests that you don't. |
|
| Back to top |
|
|
| jayZ |
| Posted: Fri Mar 15, 2013 12:16 pm Post subject: |
|
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
Sad to say that I learn more about my environment asking on this board than I get asking my admins. Turns out, the trace isn't user or service, but some other OS logging about which the admins were not specific. As for the message, the data is actually embedded in a cdata structure within another message. That embedded data uses the Windows-1252 encoding. (<?xml version = "1.0" encoding="Windows-1252" standalone="yes"?>) So far, I am pulling the encoding from the InputRoot.Properties and using a CCSID of 1208. I'll have to take another look at the encoding sent from the client and see if that is the problem. It would explain why the same basic message works when I send it but not the calling app.
As always, you have given me a different avenue to go down. Our tester is out today, but I'll dig back in Monday and see where it leads.
Thanks for the help! |
|
| Back to top |
|
|
| adubya |
| Posted: Fri Mar 15, 2013 12:21 pm Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
I read that error as there being an XML declaration in your input message but it's invalid. However guesswork is always defeated by a proper trace 
edit: missed your previous post alluding to this, good luck. |
|
| Back to top |
|
|
| jayZ |
| Posted: Mon Mar 18, 2013 12:03 pm Post subject: |
|
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
So, I finally got the trace run and it looks weird. For some reason, the XML string being deserialized is truncated, even though it is not when I view it via the debug session.
The end of the XML from the trace (shortened for readability):
| Code: |
<exportdata>
<dlr_nbr>****</dlr_nbr>
<dlr_nme>******</dlr_nme>
<str_line1_addr>******</str_line1_addr>
<str_line2_addr>P''. |
End of the XML sent by the client
| Code: |
... <str_line2_addr/>
<city_nme>MACOMB</city_nme>
<stt_abbr>IL</stt_abbr>
<zip_cd_nbr>61455</zip_cd_nbr>
<dba_nme>WOODRUM CHRYSLER/JEEP/DOD</dba_nme>
<cltr_cd>B</cltr_cd>
<auction_type>C</auction_type>
<crd_avlb_amt>100000.00</crd_avlb_amt>
<avlb_crd_ind>C</avlb_crd_ind>
</exportdata>
</VFPData>]]> |
Is it possible the trace file is just truncating the message?
The rest of the error looks like this:
| Code: |
2013-03-18 13:39:23.768674 6941 UserTrace BIP2539I: Node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans': Evaluating expression ''encoding'' at ('com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main', '35.96'). This resolved to ''encoding''. The result was ''273''.
2013-03-18 13:39:23.768692 6941 UserTrace BIP2539I: Node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans': Evaluating expression ''ccsid'' at ('com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main', '35.106'). This resolved to ''ccsid''. The result was ''1208''.
2013-03-18 13:39:23.768814 6941 UserTrace BIP2537I: Node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans': Executing statement ''DECLARE refInData REFERENCE TO xmlData.XMLNSC.VFPData;'' at ('com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main', '36.6').
2013-03-18 13:39:23.770460 6941 UserTrace BIP5004E: An XML parsing error ''The markup in the document preceding the root element must be well-formed.'' occurred on line 1 column 3 when parsing element ''/Root/XMLNSC''. Internal error codes are '1511' and '2'.
This error was reported by the generic XML parser, and is usually the result of a badly formed XML message.
Check that the input XML message is a well-formed XML message that adheres to the XML specification. The line number and column number that are quoted in the message give the position where the parser discovered the problem. However, the actual error might be earlier in the message.
Other possible causes are:
1. A character that is not supported by XML occurs in the instance message data.
XML supports only a subset of control characters; therefore, ensure that no unsupported characters, such as X'00', appear in the document.
2. The Coded Character Set ID that is defined in the message header does not reflect the contents of the instance message.
If the XML document has an XML prologue, the WebSphere MQ CodedCharSetId should be consistent with the XML Encoding field.
3. A reserved XML character appears in the instance message data.
Characters that might be recognized as XML markup - for example, < and & - should be replaced with the corresponding XML entities - < and &.
2013-03-18 13:39:26.472660 6941 UserTrace BIP2231E: Error detected whilst processing a message in node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.JMSIN'.
The message broker detected an error whilst processing a message in node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.JMSIN'. The message has been augmented with an exception list and has been propagated to the node's failure terminal for further processing.
See the following messages for details of the error.
2013-03-18 13:39:26.472692 6941 RecoverableException BIP2230E: Error detected whilst processing a message in node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans'.
The message broker detected an error whilst processing a message in node 'com.adesa.trans.customer.MF_TRANS_CUSTOMER_SOAPJMS.PROCESS.Process Toyota Dealer Eligibility.RunTrans'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2013-03-18 13:39:26.472698 6941 RecoverableException BIP2488E: ('com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main', '36.6') Error detected whilst executing the SQL statement ''DECLARE refInData REFERENCE TO xmlData.XMLNSC.VFPData;''.
The message broker detected an error whilst executing the given statement. An exception has been thrown to cut short the SQL program.
See the following messages for details of the error.
2013-03-18 13:39:26.472704 6941 RecoverableException BIP2498E: ('com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main', '36.37') : An error occurred when navigating to path element '3' of the field reference at the given location.
Further messages are generated that provide details of the error.
Correct the syntax of your ESQL expression in node ''com.adesa.trans.customer.toyota.ESQL_TRANS_CUSTOMER_TOYOTA_DLRE_RunTrans.Main'', around line and column ''36.37'', then redeploy the message flow.
2013-03-18 13:39:26.472724 6941 ParserException BIP5009E: XML Parsing Errors have occurred.
Errors have occurred during parsing of XML.
Review further error messages for an indication to the cause of the errors.
2013-03-18 13:39:26.472730 6941 ParserException BIP5004E: An XML parsing error ''The markup in the document preceding the root element must be well-formed.'' occurred on line 1 column 3 when parsing element ''/Root/XMLNSC''. Internal error codes are '1511' and '2'.
This error was reported by the generic XML parser, and is usually the result of a badly formed XML message.
Check that the input XML message is a well-formed XML message that adheres to the XML specification. The line number and column number that are quoted in the message give the position where the parser discovered the problem. However, the actual error might be earlier in the message.
Other possible causes are:
1. A character that is not supported by XML occurs in the instance message data.
XML supports only a subset of control characters; therefore, ensure that no unsupported characters, such as X'00', appear in the document.
2. The Coded Character Set ID that is defined in the message header does not reflect the contents of the instance message.
If the XML document has an XML prologue, the WebSphere MQ CodedCharSetId should be consistent with the XML Encoding field.
3. A reserved XML character appears in the instance message data.
Characters that might be recognized as XML markup - for example, < and & - should be replaced with the corresponding XML entities - < and &. |
I obviously checked the message for invalid characters and verified the same encoding ccsid is being use for both the working example and the failed. Just as a reminder, for the working sample I am just copying the XML string from my debug session on a failure and pasting it into a second request (essentually a reply). That makes me think that the problem isn't something in the string I'm trying to convert.
I am open to any and all suggestions of what to try next. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 18, 2013 12:06 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| That looks like a badly formatted CDATA section, where the bad message has not had < and > converted to < and > entites but when you manually resend, they are converted. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Mar 18, 2013 12:06 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Do a simplified recreate, with the minimum number of flows to demonstrate the problem, then submit the problem to IBM through a PMR.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| adubya |
| Posted: Mon Mar 18, 2013 12:08 pm Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
I see the ]]> characters at the end of your XML. That's a CDATA terminator, is the XML block you show part of a CDATA section ?
i.e
| Code: |
![CDATA[<VFPData>
<exportdata>
<dlr_nbr>****</dlr_nbr>
<dlr_nme>******</dlr_nme>
<str_line1_addr>******</str_line1_addr>
<str_line2_addr/>
<city_nme>MACOMB</city_nme>
<stt_abbr>IL</stt_abbr>
<zip_cd_nbr>61455</zip_cd_nbr>
<dba_nme>WOODRUM CHRYSLER/JEEP/DOD</dba_nme>
<cltr_cd>B</cltr_cd>
<auction_type>C</auction_type>
<crd_avlb_amt>100000.00</crd_avlb_amt>
<avlb_crd_ind>C</avlb_crd_ind>
</exportdata>
</VFPData>]]> |
Last edited by adubya on Mon Mar 18, 2013 12:13 pm; edited 1 time in total |
|
| Back to top |
|
|
| jayZ |
| Posted: Mon Mar 18, 2013 12:12 pm Post subject: |
|
|
Acolyte
Joined: 03 Jun 2008
Posts: 71
|
***Bad question warning***
Is that something RFHUtil does behind the scenes for me (doesn't seem plausible) or do you mean in the body of the message and not the elements themselves? I only ask because when I view the Message Data sent in my working example, I see this:
| Code: |
<TransmissionRecordGroup Type="ToyotaDlrData">
<Data>
<string><
