3 Replies Latest reply on Jun 23, 2009 2:57 AM by galder.zamarreno

Application performance issue with jboss cache

somboss May 14, 2009 8:16 AM

We have used jboss pojo cache (1.4.1.SP12) in our application. We are observing that our application runs OOM (out of memory) because of large number of jboss objects hanging around in the memory. We have confirmed that objects are being evicted but not being freed from memory.

Following are the eviction setting :

<!-- Name of the eviction policy class. -->
 <attribute name="EvictionPolicyClass">org.jboss.cache.aop.eviction.AopLRUPolicy</attribute>
 <!-- Specific eviction policy configurations. This is LRU -->
 <attribute name="EvictionPolicyConfig">
 <config>
 <attribute name="wakeUpIntervalSeconds">5</attribute>
 <!-- Cache wide default -->
 <region name="/_default_">
 <attribute name="maxNodes">100000</attribute>
 <attribute name="timeToLiveSeconds">3600</attribute>
 </region>
 </config>
 </attribute>

The objects which are not being freed are (used jmap to see the heap):

EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
[LEDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry;
org.jboss.cache.Node
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$BarrierLock
EDU.oswego.cs.dl.util.concurrent.LinkedNode
org.jboss.cache.Fqn

Please give me some inputs on this. Your help would be highly appreciated.

1. Re: Application performance issue with jboss cache

somboss May 19, 2009 12:55 AM (in response to somboss)

I found following information in PojoCache.pdf (JBoss Release 1.4.1 "Cayenne").

5.2. Detachment
Object removeObject(Fqn fqn) throws CacheException;

This call will detach the POJO from the cache management by removing the contents under fqn and return the
POJO instance stored there (null if it doesn't exist). After successfully call, any POJO operation on the returned
POJO reference is not intercepted by the cache system anymore. So in essence, you will use this Api should you
decide that the POJO under fqn is no longer necessary. For example, if a POJO is no longer in context, you will
need explicitly invoke this Api otherwise it won't get garbage collected by the VM. Note this call will also remove
everything stored under fqn even if you have put other plain cache data there.

According to this the jboss objects wont get GC unless we call removeObject, can't this be done automatically by JBoss when the object gets evicted? Or is there a way to do this by writting an Interceptor?
Actions
2. Re: Application performance issue with jboss cache

niuxuetao_fiserv Jun 22, 2009 4:21 PM (in response to somboss)

I am a user of jboss pojo cache 3.0.0, not sure of the version you are using, but for jboss cache (pojo) 3.0.0GA, you may want to read the "passivation" chapter of the jboss core edition.

A passivated object does not appear in memory, but in persistence media only. Perhaps this is what you are looking for.
Actions
3. Re: Application performance issue with jboss cache

galder.zamarreno Jun 23, 2009 2:57 AM (in response to somboss)

niuxuetao_fiserv, thanks very much for replying to this.

As niuxuetao_fiserv indicated, I'd suggest that you move to Pojo Cache 3.0.0.GA and use eviction with passivation as indicated in

http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.0.0.GA/pojo/userguide_en/html_single/index.html#d0e843

You have to bear in mind that eviction with PojoCache is not the same as eviction with core Cache because the user can still hold to a reference to an object. In other words, from PojoCache's perspective, all we can do on eviction is to untie the link between the cache and the target object itself but for it to be garbaged collected, the client code needs to make sure it doesn't hold any strong references to it any more.

The limitation though expressed by PojoCache 1.4 API is no longer applicable to PojoCache 3.0, so I'd suggest that you move to that version asap.
Actions

Go to original post