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 <dor...@gmail.com> wrote: > Thank you Mark. TransferFactory.shutdown() is working great. > > - Gabriel > > On Sun, Nov 22, 2009 at 2:25 PM, Mark Mandel <mark.man...@gmail.com> 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 <dor...@gmail.com> 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 <dor...@gmail.com> 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 <mark.man...@gmail.com> >>> > 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 <dor...@gmail.com> 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 <mark.man...@gmail.com> >>> >>> 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 <dor...@gmail.com> 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 transfer-dev@googlegroups.com >>> >>> >> To unsubscribe from this group, send email to >>> >>> >> transfer-dev-unsubscr...@googlegroups.com >>> >>> >> For more options, visit this group at >>> >>> >> http://groups.google.com/group/transfer-dev?hl=en >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > E: mark.man...@gmail.com >>> >>> > 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 transfer-dev@googlegroups.com >>> >>> > To unsubscribe from this group, send email to >>> >>> > transfer-dev-unsubscr...@googlegroups.com >>> >>> > 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 transfer-dev@googlegroups.com >>> >>> To unsubscribe from this group, send email to >>> >>> transfer-dev-unsubscr...@googlegroups.com >>> >>> For more options, visit this group at >>> >>> http://groups.google.com/group/transfer-dev?hl=en >>> >> >>> >> >>> >> -- >>> >> E: mark.man...@gmail.com >>> >> 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 transfer-dev@googlegroups.com >>> >> To unsubscribe from this group, send email to >>> >> transfer-dev-unsubscr...@googlegroups.com >>> >> 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 transfer-dev@googlegroups.com >>> To unsubscribe from this group, send email to >>> transfer-dev-unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/transfer-dev?hl=en >> >> >> -- >> E: mark.man...@gmail.com >> 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 transfer-dev@googlegroups.com >> To unsubscribe from this group, send email to >> transfer-dev-unsubscr...@googlegroups.com >> 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
