XML Parser and xml parsing problems in Coldfusion

137 views
Skip to first unread message

BarryC

unread,
Aug 16, 2010, 11:40:04 PM8/16/10
to cfaussie
Hi,

Does anyone here have experience in the field of XML Parsers, and more
specifically, the one that Coldfusion uses.
We have XML parsing problems frequently occuring on our site, the XML
Parser that is being used is the xerces one (org.apache.xerces) - at
least that's what shows up in the stack trace, but I've seen
references to alternative parsers like Crimson (which in an older post
I saw was Coldfusion's only 'supported' parser, but that was an old
post so I'm not sure if that's still the case).

Any ideas?

Thanks
Barry Chesterman

Steve Onnis

unread,
Aug 16, 2010, 11:50:18 PM8/16/10
to cfau...@googlegroups.com
What are the problems you are having?

Hi,

Any ideas?

Thanks
Barry Chesterman

--
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To post to this group, send email to cfau...@googlegroups.com.
To unsubscribe from this group, send email to
cfaussie+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cfaussie?hl=en.


Kai Koenig

unread,
Aug 16, 2010, 11:56:03 PM8/16/10
to cfau...@googlegroups.com
What's specifically the issue? Parsing problems is very general...

In general: Xerces is the current XML parser implementation in CF. I think CFMX 6 and maybe 6.1 were using Crimson internally.

Cheers
Kai

> --
> You received this message because you are subscribed to the Google Groups "cfaussie" group.
> To post to this group, send email to cfau...@googlegroups.com.
> To unsubscribe from this group, send email to cfaussie+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
>


--
Kai Koenig - Ventego Creative Ltd
ph: +64 4 476 6781 - mob: +64 21 928 365 / +61 450 132 117
web: http://www.ventego-creative.co.nz
blog: http://www.bloginblack.de
twitter: http://www.twitter.com/agentK
--

BarryC

unread,
Aug 17, 2010, 12:21:41 AM8/17/10
to cfaussie
Frequent Illegal Argument Exceptions where coldfusion will try and
access a value from the parsed result but that value will not exist
(and this isn't from dynamic XML stuff, it's from static XML files
that never change, so the values should always be there) which makes
me think that the parser is returning an invalid result without
returning a failed parse error.

Yeah I've since found that Coldfusion 9 (without any updaters) uses
Xerces 2.9.1, and that on the Xerces site there is now version 2.10.0
with a slew of bug fixes listed.
Coldfusion updater doesn't list anything to do with XML parsing fixes
so I though I might just have a crack at updating the Xerces jar used
by coldfusion.

This is normally what returns in the stack trace when the parsing or
XML dom access issue occurs:
java.lang.IllegalArgumentException: type: -1
at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown
Source)
at
org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown
Source)
at org.apache.xerces.dom.ElementImpl.getNodeName(Unknown Source)
at coldfusion.xml.XmlNodeMap.resolveElementName(XmlNodeMap.java:592)
at coldfusion.xml.XmlNodeMap.resolveName(XmlNodeMap.java:662)
at coldfusion.xml.XmlNodeMap.containsName(XmlNodeMap.java:674)
at coldfusion.runtime.Scope.containsKey(Scope.java:105)
at coldfusion.runtime.DotResolver.containsKey(DotResolver.java:362)
at coldfusion.runtime.DotResolver.containsKey(DotResolver.java:376)
at coldfusion.runtime.DotResolver.containsKey(DotResolver.java:376)
at coldfusion.runtime.DotResolver.containsKey(DotResolver.java:387)
at coldfusion.runtime.DotResolver.containsKey(DotResolver.java:407)
at
coldfusion.runtime.NeoPageContext.SymTab_symbolPartiallyExists(NeoPageContext.java:
1259)
at
coldfusion.runtime.NeoPageContext.SymTab_findReadScope(NeoPageContext.java:
1173)
at
coldfusion.runtime.NeoPageContext.SymTab_resolveSplitName(NeoPageContext.java:
1012)
at coldfusion.runtime.CfJspPage.resolveCanonicalName(CfJspPage.java:
1734)
at coldfusion.runtime.CfJspPage._resolve(CfJspPage.java:1677)
at
coldfusion.runtime.CfJspPage._resolveAndAutoscalarize(CfJspPage.java:
1812)
at
coldfusion.runtime.CfJspPage._resolveAndAutoscalarize(CfJspPage.java:
1805)
at cfsite2ecfc1225365976$funcINITREQUEST.runFunction(/path/to/the/
file/parsing/the/xml/file.cfc:190)
.....

On Aug 17, 3:56 pm, Kai Koenig <k...@koeni.de> wrote:
> What's specifically the issue? Parsing problems is very general...
>
> In general: Xerces is the current XML parser implementation in CF. I think CFMX 6 and maybe 6.1 were using Crimson internally.
>
> Cheers
> Kai
>
>
>
> > Hi,
>
> > Does anyone here have experience in the field of XML Parsers, and more
> > specifically, the one that Coldfusion uses.
> > We have XML parsing problems frequently occuring on our site, the XML
> > Parser that is being used is the xerces one (org.apache.xerces) - at
> > least that's what shows up in the stack trace, but I've seen
> > references to alternative parsers like Crimson (which in an older post
> > I saw was Coldfusion's only 'supported' parser, but that was an old
> > post so I'm not sure if that's still the case).
>
> > Any ideas?
>
> > Thanks
> > Barry Chesterman
>
> > --
> > You received this message because you are subscribed to the Google Groups "cfaussie" group.
> > To post to this group, send email to cfau...@googlegroups.com.
> > To unsubscribe from this group, send email to cfaussie+u...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/cfaussie?hl=en.

Kai Koenig

unread,
Aug 17, 2010, 12:32:40 AM8/17/10
to cfau...@googlegroups.com
So when you're saying it's a static file - is it reproducible or does it happen randomly?

Just wondering - how large are the files? Xerces is a DOM parser, i.e. holds a potentially very large XML object in memory. Maybe that could cause an issue. Is it in a shared scorpe? Some weird race conditions happening maybe (or an issue across different cluster nodes)?

Cheers
Kai

> For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.

Barry Chesterman

unread,
Aug 17, 2010, 2:46:06 AM8/17/10
to cfau...@googlegroups.com
The file or files are relatively small (about 15 lines worth mostly, and not very long lines at that), it isn't reproducible and yes it does happen randomly.
There isn't any memory issue, the scope when the file is read is local only to the particular request (I'm pretty sure - I'll check), It could be related to multiple page requests running simultaneously trying to parse that same file, we do have multiple servers in a cluster that point at a shared file store, so as well as multiple requests on the same server accessing that file, there are other requests on different servers also accessing that file, but there are no file access issues for anything else, just the XML parsing stuff.

Mark Mandel

unread,
Aug 17, 2010, 2:52:10 AM8/17/10
to cfau...@googlegroups.com
I wonder if there are any threading issues in the xml parser.

Try locking down the reading of the xml file, and see if that resolves the issue.

It may be that people don't tend to see this issue because it's a common practice to read the xml file that never change once, and then just cache it in memory for future use.

Mark
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australia
http://www.cfobjective.com.au

Hands-on ColdFusion ORM Training
www.ColdFusionOrmTraining.com

Barry Chesterman

unread,
Aug 17, 2010, 3:37:57 AM8/17/10
to cfau...@googlegroups.com
I wonder that too.

When you say lock it down, do you mean put an lock around the file read using the cflock?
I can give that a go and see if the issue still occurs as that is something relatively easy to test.

And yes you would expect to cache static XML files (at least) to save having to read and parse it every single page load, but unfortunately we use a third party system which we can't really change :(. Though in saying that, I'm pretty sure it also occurs on other areas where XML is cached for a period of time and thus read a lot less, but I'd have to double check that.

Thanks :)
Barry.

Mark Mandel

unread,
Aug 17, 2010, 3:47:05 AM8/17/10
to cfau...@googlegroups.com
Yup, exactly what I mean :)


On Tue, Aug 17, 2010 at 5:37 PM, Barry Chesterman <barrych...@gmail.com> wrote:
When you say lock it down, do you mean put an lock around the file read using the cflock?



Mark Mandel

unread,
Aug 17, 2010, 3:47:31 AM8/17/10
to cfau...@googlegroups.com
Actually, to be clear, around the XMLParse more than the file read.

Mark

BarryC

unread,
Aug 17, 2010, 10:55:17 PM8/17/10
to cfaussie
I have worked out what the issue is (YAY),

It appears that it is a case of un-vared variables, the variable that
the parsed XML is being read into is not scoped in a cfc function,
causing any reads for from that variable to fail if another process is
writing to it - seeings it becomes a global variable having not been
vared.
Trying a lock around the variables before I properly scoped them also
worked showing that multiple processes would have been trying to read/
write those values at the same time.
I was able to re-produce the errors by load testing our dev box with
25 odd simultaneous users requesting the same page.

I will now go and annoy the vendors :)

Thanks for the help and suggestions.

Barry.

On Aug 17, 7:47 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> Actually, to be clear, around the XMLParse more than the file read.
>
> Mark
>
>
>
> On Tue, Aug 17, 2010 at 5:47 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > Yup, exactly what I mean :)
>
> > On Tue, Aug 17, 2010 at 5:37 PM, Barry Chesterman <
> > barrychester...@gmail.com> wrote:
>
> >> When you say lock it down, do you mean put an lock around the file read
> >> using the cflock?
>
> > --
> > E: mark.man...@gmail.com
> > T:http://www.twitter.com/neurotic
> > W:www.compoundtheory.com
>
> > cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australia
> >http://www.cfobjective.com.au
>
> > Hands-on ColdFusion ORM Training
> >www.ColdFusionOrmTraining.com
>
> --
> E: mark.man...@gmail.com
Reply all
Reply to author
Forward
0 new messages