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
