Specifically during my testing, the error was caused in file: transfer\com\cache\provider\EHCacheProvider.cfc
Line 89: <cfif NOT getEHCacheManager().cacheExists(arguments.class)> Line 121: if(NOT getEHCacheManager().cacheExists(arguments.class)) - Gabriel On Mon, Nov 23, 2009 at 9:44 PM, Dorioo <[email protected]> wrote: > Hi Mark, > > A. Now that the cache can be "shutdown", I've been able to create an > error where a page loads several transfer objects and in the middle of > that process, another page reinitializes the application which > recreates Transfer and therefore ehcache. When that happens, I get the > following error: > > "The CacheManager has been shut down. It can no longer be used." > > This error appears to center around the use of the "cacheExists()" > method in "getEHCacheManager().cacheExists(arguments.class)" > > B. Looking at the ehcache api, there is a "checkStatus()" function > that "checks the state of the CacheManager for legal operation". > Before interacting with ehcache in the code, you may have to first > check if the cache status is "alive" otherwise it's not viable for use > and appears to cause this error. > > STATUS_UNINITIALISED - The cache is uninitialised. It cannot be used. > STATUS_ALIVE - The cache is alive. It can be used. > STATUS_SHUTDOWN - The cache is shudown. It cannot be used. > > - Gabriel > > On Mon, Nov 23, 2009 at 8:40 PM, Dorioo <[email protected]> wrote: >> Thank you Mark. TransferFactory.shutdown() is working great. >> >> - Gabriel >> >> On Sun, Nov 22, 2009 at 2:25 PM, Mark Mandel <[email protected]> wrote: >>> Now that IS interesting! >>> >>> Looks like I overlooked something with EHCache. >>> >>> EHCache will need to be shutdown when the application stops: >>> >>> http://ehcache.org/documentation/shutdown.html >>> >>> So that the timer threads and the like can stop working, otherwise, it will >>> hang around forever. >>> >>> This should be easy enough to do via onApplicationEnd() (Good thing this >>> won't work on CF8). >>> >>> I'll expose the EHCacheManager through the CacheMonitor (which is the last >>> thing on the Monitor I need to do), but I'm wondering if it makes more sense >>> to have a TransferFactory.shutdown() method as a general method, which calls >>> similarly on the CacheProvider, that needs to be called onApplicationEnd... >>> or if it's worth simply doing this by a cache by cache basis through the >>> CacheMonitor. >>> >>> Mark >>> >>> >>> On Mon, Nov 23, 2009 at 4:15 AM, Dorioo <[email protected]> wrote: >>>> >>>> Some additional info. Looking at the threads in visualvm and there are >>>> many "net.sf.ehcache.CacheManager" threads all in "waiting" status for >>>> hours now as I kept the hanging version running overnight. >>>> >>>> When I ask it for a threaddump, it gave me entries like the following >>>> which reference the timerthread class like in my previous email. >>>> >>>> "net.sf.ehcache.cachemana...@105ec7e" - Thread t...@217 >>>> java.lang.Thread.State: TIMED_WAITING on java.util.taskqu...@124f8b0 >>>> at java.lang.Object.wait(Native Method) >>>> at java.util.TimerThread.mainLoop(Timer.java:509) >>>> at java.util.TimerThread.run(Timer.java:462) >>>> >>>> Locked ownable synchronizers: >>>> - None >>>> >>>> - Gabriel >>>> >>>> On Sun, Nov 22, 2009 at 7:54 AM, Dorioo <[email protected]> wrote: >>>> > I'm sort of winging this so I hope this is correct. I clicked on one >>>> > of the instances of the cachemanager >> "path to GC Roots" >> "with >>>> > all references" >>>> > >>>> > net.sf.ehcache.CacheManager >>>> > -- [26] java.lang.Object[] >>>> > ---- array java.util.concurrent.CopyOnWriteArrayList >>>> > ------ ALL_CACHE_MANAGERS net.sf.ehcache.CacheManager >>>> > -------- [19] java.lang.Object[] >>>> > ---------- elementData java.util.Vector >>>> > ------------ classes com.compoundtheory.classloader.NetworkClassLoader >>>> > -------------- <classloader> net.sf.ehcache.util.UpdateChecker >>>> > ---------------- <class> net.sf.ehcache.util.UpdateChecker >>>> > ------------------ <Java Local> java.util.TimerThread >>>> > ---------------- <class> net.sf.ehcache.util.UpdateChecker >>>> > ------------------ <Java Local> java.util.TimerThread >>>> > ---------------- <class> net.sf.ehcache.util.UpdateChecker >>>> > ------------------ <Java Local> java.util.TimerThread >>>> > ---------------- <class> net.sf.ehcache.util.UpdateChecker >>>> > ------------------ <Java Local> java.util.TimerThread >>>> > - continue - >>>> > >>>> > There are 30 entries for "<class> net.sf.ehcache.util.UpdateChecker" >>>> > and each one has a "<Java Local> java.util.TimerThread" that is >>>> > decorated with a yellow dot. >>>> > >>>> > - Gabriel >>>> > >>>> > On Sun, Nov 22, 2009 at 1:11 AM, Mark Mandel <[email protected]> >>>> > wrote: >>>> >> So if you look at a EHCacheManager with respect to it's GC roots - what >>>> >> is >>>> >> holding it in place? >>>> >> >>>> >> Mark >>>> >> >>>> >> On Sun, Nov 22, 2009 at 4:57 PM, Dorioo <[email protected]> wrote: >>>> >>> >>>> >>> Yeah. Basically I reinit the app, load a page that has transfer >>>> >>> objects (12-36 of them) and repeat for about 30 minutes. >>>> >>> >>>> >>> 1. With Pluggable Cache: -XX:+HeapDumpOnOutOfMemoryError dumped out a >>>> >>> heap file and below are some values from MAT dominator >>>> >>> >>>> >>> Class: net.sf.ehcache.CacheManager >>>> >>> Retained Heap: 446MB >>>> >>> Percentage: 86.41% >>>> >>> >>>> >>> 2. With SVN Transfer - did not crash. Twice, the used heap reached >>>> >>> ~500MB and drastically dropped to ~100MB >>>> >>> >>>> >>> 3. Second run of pluggable cache. Hasn't crashed yet but the site is >>>> >>> not accessible. I used VisualVM to take a heap. >>>> >>> >>>> >>> Class: net.sf.ehcache.CacheManager >>>> >>> Retained Heap: 444MB >>>> >>> Percentage: 89.79% >>>> >>> >>>> >>> Again, I ran into this while developing because reinitializing the app >>>> >>> occurs often as you develop. Reiniting that often would not occur in >>>> >>> production so it may not be a problem but I'm just trying to >>>> >>> conceptually understand what's happening. I attribute the drastic drop >>>> >>> in the second test run to the softreferences in the SVN transfer but I >>>> >>> am lost on the cause of the first and third runs as you've stated that >>>> >>> they should be garbage collected. >>>> >>> >>>> >>> - Gabriel >>>> >>> >>>> >>> On Sat, Nov 21, 2009 at 8:02 PM, Mark Mandel <[email protected]> >>>> >>> wrote: >>>> >>> > The CacheManager should be garbage collected. >>>> >>> > >>>> >>> > What exactly is the problem you are seeing OutOfMemory errors? >>>> >>> > >>>> >>> > Mark >>>> >>> > >>>> >>> > On Sun, Nov 22, 2009 at 8:37 AM, gabriel <[email protected]> wrote: >>>> >>> >> >>>> >>> >> Disclaimer: Not a java person >>>> >>> >> >>>> >>> >> A. I have a coldbox app and every time I reinitialize the >>>> >>> >> application, >>>> >>> >> a new instance of "net.sf.ehcache.CacheManager" is created. I've >>>> >>> >> looked at the heap dump and it seems like instances of that class >>>> >>> >> are >>>> >>> >> taking up 85% of the available memory. >>>> >>> >> >>>> >>> >> What I believe is happening is that coldbox creates a new instance >>>> >>> >> of >>>> >>> >> transfer when you reinitialize the application and transfer then >>>> >>> >> creates a new instance of ehcache. >>>> >>> >> >>>> >>> >> B. I'm wondering, from Transfer's perspective..... >>>> >>> >> >>>> >>> >> 1. Is the intention that only one instance of Transfer exist, say >>>> >>> >> in >>>> >>> >> the Application scope, which ensures that only one instance of the >>>> >>> >> ehCache CacheManager exists as the Application scope is generally >>>> >>> >> not >>>> >>> >> changed until you restart coldfusion? >>>> >>> >> >>>> >>> >> 2. Or, do those instances of "net.sf.ehcache.CacheManager" go away >>>> >>> >> at >>>> >>> >> some point (doesn't seem like it) ? >>>> >>> >> >>>> >>> >> 3. Or, is there a way to manually discard them when a new instance >>>> >>> >> of >>>> >>> >> Transfer is created? >>>> >>> >> >>>> >>> >> Thank you, >>>> >>> >> Gabriel >>>> >>> >> >>>> >>> >> -- >>>> >>> >> 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 >>>> >>> > >>>> >>> > -- >>>> >>> > 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 >>>> >> >>>> >> >>>> >> -- >>>> >> 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 >>>> > >>>> >>>> -- >>>> 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 >>> >>> -- >>> 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
