The question be-gets itself - why are you re-initialising Transfer mid thread?
Is this in a production environment? Mark On Tue, Nov 24, 2009 at 1: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 > -- 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
