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. On Tue, Aug 17, 2010 at 6:52 PM, Mark Mandel <[email protected]> wrote: > 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 > > On Tue, Aug 17, 2010 at 4:46 PM, Barry Chesterman < > [email protected]> wrote: > >> 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. >> >> >> On Tue, Aug 17, 2010 at 4:32 PM, Kai Koenig <[email protected]> wrote: >> >>> 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 >>> >>> On 17/08/2010, at 4:21 PM, BarryC wrote: >>> >>> > 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 <[email protected]> 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 [email protected]. >>> >>> To unsubscribe from this group, send email to >>> [email protected]<cfaussie%[email protected]> >>> . >>> >>> For more options, visit this group athttp:// >>> 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 >>> >> -- >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "cfaussie" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> [email protected]<cfaussie%[email protected]> >>> . >>> > 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 >>> -- >>> >>> >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "cfaussie" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<cfaussie%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/cfaussie?hl=en. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "cfaussie" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<cfaussie%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/cfaussie?hl=en. >> > > > > -- > E: [email protected] > 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 > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<cfaussie%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
