I would probably be 2000 elements per class. Mark
On Tue, Feb 9, 2010 at 7:09 AM, Dorioo <[email protected]> wrote: > I set maxelementsinmemory to 2000 for both the object and template cache. > No other changes beside setting those values. > > Although, the thought dawned on me today whether that value was being used > overall or per class. Still, too many variables right now. User error, beta > coldbox, beta transfer, and CF9 bit me in the butt with that "local" problem > so I'm considering it a variable as well. > > - Gabriel > > On Mon, Feb 8, 2010 at 2:34 PM, Mark Mandel <[email protected]> wrote: > >> How much had you configured your CF9 eHCache instance? >> >> Or had you left it so lots of stuff got cached? >> >> Mark >> >> On Tue, Feb 9, 2010 at 1:50 AM, Dorioo <[email protected]> wrote: >> >>> I'm ending this experiment for now and using the default ehCache >>> provider. Over time, the experimental CF9 cache provider led to out of >>> memory issues. >>> >>> Biggest Top-Level Dominator Classes: coldfusion.runtime.TemplateProxy >>> (77.62% retained heap) >>> Biggest Top-Level Dominator Class Loaders: >>> coldfusion.bootstrap.BootstrapClassLoader >>> (92.04% retained heap) >>> >>> >>> - Gabriel >>> >>> On Fri, Jan 22, 2010 at 11:07 AM, Dorioo <[email protected]> wrote: >>> >>>> Found the cause. The appender was defining "getScope()" and returning >>>> "none". This makes sense in the "NoCache" appender but makes no sense in a >>>> real appender. >>>> >>>> It's not even one of the "VirtualMethodException" functions mentioned by >>>> Mark so need to define it. Removed it and back to "so far, so good". >>>> >>>> - Gabriel >>>> >>>> >>>> On Fri, Jan 22, 2010 at 10:26 AM, Dorioo <[email protected]> wrote: >>>> >>>>> hmm. Cache not updating on many to one updates unless parent explicitly >>>>> discarded. >>>>> >>>>> :( Back to testing. >>>>> >>>>> - Gabriel >>>>> >>>>> >>>>> On Wed, Jan 20, 2010 at 5:15 PM, Dorioo <[email protected]> wrote: >>>>> >>>>>> A. Yup, that's what I'm referring to. :-) I don't want to be >>>>>> responsible for calling shutdown(). >>>>>> >>>>>> What was bothering me is the case where say, you're reinitlizating >>>>>> your app, transfer gets loaded, and a bad error happens that stops the >>>>>> initialization process midway. You're then left with an instance of >>>>>> ehcache >>>>>> and no way to shut it down. >>>>>> >>>>>> Granted this should be an edge exception in production but led me to >>>>>> this experiment. >>>>>> >>>>>> B. Attached is what I have so far. It's all cache and no statistics >>>>>> but maybe others will find it useful. >>>>>> >>>>>> 1. The CF9 object cache is _not_ exclusive to this provider so I >>>>>> didn't incorporate any settings for the cache. Those should be set >>>>>> elsewhere >>>>>> in your app using CacheSetProperties() >>>>>> 2. Currently extends >>>>>> "transfer.com.cache.provider.AbstractBaseProvider" so it's assuming >>>>>> you have >>>>>> a "/transfer" mapping. Change as needed >>>>>> 3. ShutDown() simulates the existing ehCache implementation by >>>>>> discarding all related objects. However, if this call were to fail or >>>>>> never >>>>>> be called, the object themselves timeout and so they'll eventually be >>>>>> purged >>>>>> regardless of whether shutdown() fails or is never called. >>>>>> 4. Usage example below where timeSpan and idleTime are minutes, >>>>>> required, and are explained in the CF9's CachePut() function. >>>>>> >>>>>> <defaultcache >>>>>> provider="transfer.path.to.this.file.antCF9CacheProvider"> >>>>>> <setting name="timeSpan" value="30"/> >>>>>> <setting name="idleTime" value="15"/> >>>>>> </defaultcache> >>>>>> >>>>>> - Gabriel >>>>>> >>>>>> On Wed, Jan 20, 2010 at 4:12 PM, Mark Mandel >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> On Thu, Jan 21, 2010 at 2:34 AM, Dorioo <[email protected]> wrote: >>>>>>> >>>>>>>> Main benefit I was looking for is not having to manage the ehCache >>>>>>>> instance myself. >>>>>>> >>>>>>> >>>>>>> You know the eHCache provider in Transfer manages this for you? You >>>>>>> just call .shutdown() on transfer, and the ehCache Cache is shutdown >>>>>>> properly. No more management than that necessary. >>>>>>> >>>>>>> >>>>>>>> If I fail to properly shutdown an ehcache instance, it remains in >>>>>>>> memory. Using the CF9 object cache, I simulate a "shutdown" by >>>>>>>> discarding >>>>>>>> all of the objects in the CF9 object cache that begin with my providers >>>>>>>> naming prefix. And if that were to fail for any reason, the objects >>>>>>>> themselves have a timeout and would be purged in time anyway by CF9. >>>>>>>> >>>>>>>> Obvious limitations are with the limited ways in which CF9 allows >>>>>>>> you to interact with its object cache but so far it's looking viable >>>>>>>> for my >>>>>>>> needs. >>>>>>>> >>>>>>> >>>>>>> When you get it finished, feel free to post it to the list, and I can >>>>>>> add it as a cache provider in Transfer. >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> -- >>>>>>> E: [email protected] >>>>>>> T: http://www.twitter.com/neurotic >>>>>>> W: www.compoundtheory.com >>>>>>> >>>>>>> Hands-on ColdFusion ORM Training @ cf.Objective() 2010 >>>>>>> www.ColdFusionOrmTraining.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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> -- >>> 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]<transfer-dev%[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 >> >> Hands-on ColdFusion ORM Training @ cf.Objective() 2010 >> www.ColdFusionOrmTraining.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]<transfer-dev%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/transfer-dev?hl=en >> > > -- > 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]<transfer-dev%[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 Hands-on ColdFusion ORM Training @ cf.Objective() 2010 www.ColdFusionOrmTraining.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
