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] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
