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

    Application performance issue with jboss cache

      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

          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?

          • 2. Re: Application performance issue with jboss cache
            niuxuetao_fiserv

            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.

            • 3. Re: Application performance issue with jboss cache
              galder.zamarreno

              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.