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
