Hello Mark, hello all, I've been working on my memory leak this week, it's a real nightmare to identify my problem. I've learn a lot thanks to excellent blog about JRockit and co (I feel less alone...).
I moved to the ehCache version (clearly faster), but my issue is still the same (see attached with 10 users during 20 minutes...). The point is when I deactivate the cache, there is no leak. When the cache is activated former one or new one, there is a leak of cfTransferObject2ecfc47864934 objects (thousands growing). No doubt there is a problem in our own code, I continue my investigation but it's hard to define where it is... By the way, I try to move to CF9. I've got good results without any changes. It seems that the memory is still here but very very little. With CF9, I've see this problem : SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/dev/bin/ColdFusion9/runtime/../lib/slf4j-log4j12-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/dev/workspace/lib/transfer.eh/com/cache/provider/ehcache-lib/slf4j-log4j12-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. I don't know if there is something to do with. I'll keep you informed... Aurelien 2009/12/14 Mark Mandel <[email protected]> > If anyone is using the EHCacheProvider, I would suggest updating. > > Elliot Sprehn and I found some bugs and performance tweaks together today > that should fix several things that have been committed to SVN. > > Mark > > > On Mon, Dec 7, 2009 at 10:19 PM, Mark Mandel <[email protected]>wrote: > >> About to go to bed - but just committed to SVN a >> AbstractBaseAsyncDiscardProvider - that allows for object discards to be >> fire asynchronously. >> >> This is a big plus for the EHCacheProvider (which uses this), because it >> won't lock down a object load while waiting for a discard to fire, which can >> happen when doing a get() request. >> >> More tomorrow... >> >> Mark >> >> >> On Tue, Dec 1, 2009 at 9:56 AM, Mark Mandel <[email protected]>wrote: >> >>> Just got my own write up done: >>> http://www.compoundtheory.com/?action=displayPost&ID=447 >>> >>> Mark >>> >>> >>> On Thu, Nov 26, 2009 at 12:46 PM, Brian G <[email protected]>wrote: >>> >>>> >>>> On Nov 23, 2:38 pm, Mark Mandel <[email protected]> wrote: >>>> > > How would you suggest handling this? Some kind of generic teardown? >>>> > >>>> > Sounds good to me :D >>>> >>>> Working like this (based on >>>> http://www.mail-archive.com/[email protected]/msg00730.html >>>> ): >>>> >>>> <cffunction name="setUp" returntype="void" access="public"> >>>> <cfscript> >>>> variables.beanFactory = createObject("component", >>>> "coldspring.beans.DefaultXmlBeanFactory").init(); >>>> >>>> variables.beanFactory.loadBeansFromXmlFile("/setup/coldspring.xml", >>>> true); >>>> >>>> variables.transferFactory = variables.beanFactory.getBean >>>> ("ormService"); >>>> variables.transferFactory.getTransaction().advise(this, >>>> "^test"); >>>> </cfscript> >>>> </cffunction> >>>> >>>> <cffunction name="tearDown" output="false" access="public" >>>> returntype="any" hint=""> >>>> <!--- shutdown transfer cache ---> >>>> <cfset variables.transferFactory.getTransfer().discardAll() /> >>>> <cfset variables.transferFactory.shutdown() /> >>>> </cffunction> >>>> >>>> <cffunction name="testPrepareEventThingy" output="false" >>>> access="public" returntype="void"> >>>> ... >>>> ... >>>> ... >>>> >>>> <cftransaction action="rollback" /> >>>> </cffunction> >>>> >>>> The only bummer to this approach is putting the rollback at the bottom >>>> of every single test function. Is there a way to make the advice run >>>> a function with the rollback automatically when it completes? >>>> >>>> Thanks! >>>> >>>> >>>> Brian >>>> >>>> -- >>>> Before posting questions to the group please read: >>>> >>>> http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "transfer-dev" 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/transfer-dev?hl=en >>>> >>> >>> >>> >>> -- >>> E: [email protected] >>> T: http://www.twitter.com/neurotic >>> W: www.compoundtheory.com >>> >>> >> >> >> -- >> E: [email protected] >> T: http://www.twitter.com/neurotic >> W: www.compoundtheory.com >> >> > > > -- > E: [email protected] > T: http://www.twitter.com/neurotic > W: www.compoundtheory.com > > -- > Before posting questions to the group please read: > > http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer > > You received this message because you are subscribed to the Google Groups > "transfer-dev" 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/transfer-dev?hl=en > -- Aurélien Deleusière Mobile : +33 (0)6 83 78 83 42 ad e-consulting expertise 2.0 104, Grande Rue - 92310 Sèvres S.A.R.L. au capital de 8500€ R.C.S. Nanterre 50177609000018 -- Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" 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/transfer-dev?hl=en
<<attachment: memory.png>>
