Concept Question: Do "net.sf.ehcache.CacheManager" instances go away or is there a way to manually get rid of them?

[gabriel]

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

[Mark Mandel]

The CacheManager should be garbage collected.

What exactly is the problem you are seeing OutOfMemory errors?

Mark

--
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 transf...@googlegroups.com
To unsubscribe from this group, send email to transfer-dev...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

[Dorioo]

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

[Mark Mandel]

So if you look at a EHCacheManager with respect to it's GC roots - what is holding it in place?

Mark

[Dorioo]

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

[Dorioo]

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.CacheManager@105ec7e" - Thread t@217
java.lang.Thread.State: TIMED_WAITING on java.util.TaskQueue@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

[Mark Mandel]

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

[Dorioo]

Thank you Mark. TransferFactory.shutdown() is working great.

- Gabriel

[Dorioo]

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

[Dorioo]

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

[Mark Mandel]

The question be-gets itself - why are you re-initialising Transfer mid thread?

Is this in a production environment?

Mark

[Dorioo]

It's currently in development but it's meant to simulate deploying new
code to production. As part of the deploy interceptor in Coldbox, it
automatically "reinitializes" the application after deployment which
could possibly be mid-thread with real users on the site.

So my thinking was that the ehcachemanager, if shutdown, could then
act as though as though no cache exists. Although, as you point it out
now, I see how it could create some problems. Hmm...

- Gabriel