Guys, Thanks for your comments.
I do understand completely the common CF gotchas. I should have stated that I've done a fair bit of this stuff before with CF and the commercial BD engines and i've been stepping through this particular one and got to the point where I could tell from experience its something amiss/leaking. My hunch with XML being the route cause was going back to the issue we had getting our framework to work with Commercial Bluedragon in the first place. I'm putting together a test case but essentially I have one XML file persisted into application scope, effectively its a site tree using nodes of sections and pages for our CMS framework. This is a tiny demo site im playing with 66k site definition file but some of our production sites have massive XML files 30MB in some cases, so I know the app itself is solid. Essentially my XML file is used with large amounts of xpath to do all manner of things from navigation to breadcrumbs. Running the following on apache bench to create some load ab -c20 -n1000 http://10.0.10.37:8888/ >From trial and error stepping through and watching the memory I found the point in the framework where it goes wrong. I have a core function which reads a physical xml file into memory and then from that point on all interactions with the xml are done against the memory resident copy. The function is one of the oldest points in our framework a UDF which itself is non persisted (This framework was originally written for Coldfusion MX and as you guys will remember CFC performance sucked originally) <cffunction name="ReadSiteTree"> <cfset var xmltree=""> <cfif not StructKeyExists(application[application.sitename],"tree") or (StructKeyExists(request,"flushsitetree") and request.flushsitetree)> <cflock name="#application['sitetreefile']#" timeout="10" type="readonly" throwontimeout="yes"> <cffile action="read" file="#application.sitetreefile#" variable="xmltree" charset="utf-8"> <cfset application[application.sitename]["tree"]=xmlparse(xmltree)> <cfreturn application[request.sitename]["tree"]> </cflock> <cfelse> <cfreturn application[request.sitename]["tree"]> </cfif> </cffunction> <!--- the read ---> <cfset xmltree=readSiteTree()> <!--- the xpath search ---> <cfset test=XMLSearch(xmltree,'//page')> So the above is vastly simplified the Xpaths we're actually running are more complex but this example alone will cave the server when i hit it with load, I will put together a standalone test case, essentially if I abort processing after the read the memory doesn't go up noticably no matter whether we have 10 sessions or 10,000 however as soon as i do the XMLSearch the memory climbs and runs out. The other behaviour is the actual XML object gets corrupted so some strange weirdness but again stuff sometimes goes that way when you chuck load on it. The important thing is other than the one variable persisted in app scope everything is just in variables scope. The test server is BD 1.4 Viviotech installer on tomcat running under Windows 2008 64bit server. Will create a standalone test case and try it on the ready to run on OSX -- tag/function ref: http://www.openbluedragon.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en Get to Texas in Feb for OpenCFSummit http://www.opencfsummit.org/
