One reason I ask is that I've done quite a bit of work on trying to resolve this exact issue in an application we're working now.
I did find a couple of relevant posts, that appear to address the issue. We're still having some problems with other code, but fixing the "missing output attribute" problem seemed to resolve a good deal of the problems we were having. http://www.bytestopshere.com/post.cfm/must-read-coldspring-bug-memory-leak http://blog.maestropublishing.com/fixing-a-mysterious-memory-leak-on-coldfusion We also ran through with varscoper, and found one place in particular where a non-var scoped variable was hurting us big time. But I think pointing to a var scoping issue as a memory leak would be a rare occasion -- more likely just a big problem with incorrect data. I'm really curious what other folks have experienced as regards the hard-bind issue. I know many are using frameworks that would experience this issue, so I can't imagine it has gone unnoticed. Cheers, Kris On Wed, Jul 14, 2010 at 10:52 AM, Andrew Clarke <s...@clarke.ca> wrote: > > I don't recall 100% what the problem was, but I'll tell you what I remember. > I built www.knappfast.com a few years ago using ColdBox & ColdSpring. If you > look at the site, bear in mind that I have nothing to do with the look & > feel, and that it was started in 2007 ;-) For various reasons, it just went > live last month. > > Anyway, there were some singleton objects, and some other objects. There > were some instances where I tried to put a singleton into other objects. For > example, I'd have, say, a cart. Each user would have his/her own cart, but > there would only need to be one cart DAO. So I put the cart DAO in as > cart.DAO so I could do something like cart.DAO.save(). I'm simplifying > things a bit but you get the idea. CartDAO was probably saved as a singleton > in ColdSpring. > > I also have some very large objects that can store a LOT of data. There are > some processes that pull tens of thousands of products, so if a bunch of > those aren't released, you'll see memory climb very rapidly and then not get > released. > > The issue was that if CartDAO was saved in the application or session scope, > the cart object wouldn't GC properly as it had a handle on an > application-scoped object. I tried a few things, including: > > 1. Changing JVM arguments to allow a larger max memory size > (-XX:MaxPermSize=768m). While this certainly helped, it really only helped > to delay the problem rather than to eliminate it. > > 2. Using structCopy(). However, structCopy() only copies the topmost part of > a structure (or object) by value and copies everything else by reference. > Therefore this didn't resolve the problem. > > 3. Using duplicate(). IIRC this helped in development on CF9 but when I went > to deploy on CF7 I found out that you can't use duplicate() on objects, only > generic structures. > > 4. Ripping out ColdBox and ColdSpring. I wrote my own very lightweight > replacement framework that only does the things I need it to do. This helped > a lot as I now have fewer black boxes in my code, and things run a lot faster > and consume less memory. > > 5. I also tried explicitly calling garbage collection at the end of every > request: > > var obj = createObject("java","java.lang.System"); > obj.gc(); > obj.runFinalization(); > > This certainly adds a bit of overhead to every page request and I wouldn't > recommend this specific approach to a high-volume site, but it tends to bring > down memory usage more quickly than waiting for Java to GC. However, it > doesn't resolve the core problem if garbage collection isn't releasing the > memory anyway. > > 6. Finally, I ended up realizing what the problem was and stopped using > session and application singletons. I now create a per-request singleton > object that gets destroyed along with the rest of the request. It's not a > high-volume site and this was a better solution than re-architecting > everything to allow session or application-based singletons. > > I'm sure there are others on here who have done a better job of avoiding, > identifying, and/or resolving this issue, but these are the steps I went > through. > > - Andrew. > > On 2010-07-14, at 06:42, Kris Jones wrote: > >> >> Andrew, >> >> Can you elaborate on the problems you've seen loading Application >> scoped objects into the request scope? We're having some problem with >> this as well, re: garbage-collection. Is there any documentation you >> can point me at for this issue? >> >> What alternative do you recommend? Just always calling the >> shared-scope object directly, instead of referencing the request >> scoped object? For what it's worth, the request scoped object would >> just be a pointer to the App-scoped object. So on request end, the >> pointer should be set null, and should be garbage-collectable, right? >> >> Cheers, >> Kris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:335369 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
