Posted: Tue Sep 06, 2011 8:45 am Post subject: Intermittent XML parser error
Knight
Joined: 25 Aug 2006 Posts: 589
I am using WMB 61 CSD 5 on AIX. My message flow failed intermittently with parser error during the over night production run.. The Input Node is FileINput with XMLNSC as the parser.
The error description is :
Element type "D" must be followed by either attribute specifications, ">" or "/>"
Sometimes it says
Attribute name "D" must be followed by the ''='' character
The xml file was checked to be well-formed. I can always replay the file with no error after the failure which is normally the following morning. We suspect that it may be due to heavy system load at the time. However we like to get closer to the problem.
Can anyone help me to understand what exactly is "Element type "D" or Attribute name "D" ? In the xml , we have no XML tag or attribute with just the name "D". We have a number of XML Tag that deals with "Discount" which begins with the letter "D".
The error message some time give us more information such as "Cause of error is 1516. 2. 1. 1486849..." Which I think points to line 1 column 1486849. I tried to interpet that as character 1486849 from the beginning of the xml file. But that is not pointing the the tag that starts with "D".
Any suggestion on how I can get closer to the problem ?
Error messages from XMLNSC usually include a line number and a character offset. However...this does not sound like 'business as usual'. It may be a defect that only occurs when the parser is operating on multiple threads at the same time. Probably best to open a PMR. IBM service will probably want quite a lot of information to help them reproduce/diagnose the problem.
Hi Kimbert, thanks for the reply.
Is "Cause of error is 1516. 2. 1. 1486849..." the "Error messages from XMLNSC usually include a line number and a character offset" that you are referring to ? But 1486849 does not point to anything that refer to "D".
I like to open a PMR. But I cannot recreate the failure. The failing file always works the following morning. I just have to move it from the mqsibackout folder back to the Input folder. I can not run traces all night long because the failure is intermittent. That's why I am looking for any suggestion to narrow this down. I'll open a PMR with IBM to see if they have any suggestion.
The most likely cause here is that the process that is writing the file is doing something to convince the FileInput node that the file is complete and ready to be read before it is actually complete.
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