5 Replies Latest reply on May 23, 2011 10:52 PM by richard yang

    Seam 3 transaction 3.0.0.Final possible memory leaks?

    richard yang Newbie

      I have been doing some performance testing on cdi beans with @TransactionalAttribute in jboss AS 6 final.
      After my application runs for a while (I have created 10 threads constantly invoking the ApplicaitonScoped bean to get data from database and them update those data), I got got exception:: java.lang.OutOfMemoryError: GC overhead limit exceeded.


      I analyzed the heap dump with eclipse memory analyzer and it suspects that the seam 3 transaction interceptor might have memory leaks. Please see the attached screen shot.

        • 1. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
          richard yang Newbie


          "
          One instance of "org.jboss.weld.context.CreationalContextImpl" loaded by "org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08" occupies 387,677,848 (40.99%) bytes. The memory is accumulated in one instance of "java.lang.Object[]" loaded by "<system class loader>".
          I could not find a way to upload the screen shot.
          I am posting the text instead:
          
          Keywords
          java.lang.Object[]
          org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08
          org.jboss.weld.context.CreationalContextImpl
          
          
           Shortest Paths To the Accumulation Point
          Class Name Shallow Heap Retained Heap 
          java.lang.Object[198578] @ 0xf2c419b8 1,588,648 387,677,288 
          elementData java.util.ArrayList @ 0xde867580 40 387,677,328 
          list, c java.util.Collections$SynchronizedRandomAccessList @ 0xde867568 40 387,677,368 
          dependentInstances org.jboss.weld.context.CreationalContextImpl @ 0xde867418 48 387,677,848 
          creationalContext org.jboss.weld.bean.builtin.InstanceImpl @ 0xde8673e0 56 88 
          transaction org.jboss.seam.transaction.TransactionInterceptor @ 0xde867330 40 584 
          instance org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation @ 0xfc2cf5a8 40 80 
          [0] java.lang.Object[10] @ 0xfc2cf570 104 184 
          elementData java.util.ArrayList @ 0xfc2cf558 40 224 
          interceptorMethodInvocations org.jboss.interceptor.proxy.SimpleInterceptionChain @ 0xfc2cf530 64 984 
          <Java Local> java.lang.Thread @ 0xdef53810 pool-109-thread-2 Thread 176 44,120 
          value java.util.HashMap$Entry @ 0xde867310 » 48 48 
          Total: 2 entries 
          
          "



          • 2. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
            Thomas Andraschko Newbie

            i faced a similar problem using a small faces/persistence test application

            • 3. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
              richard yang Newbie

              It turns out the OOM was because of this:


              We had Bean A injects another Bean B. Both bean had @TransactionAttribute annotated on class level. After I removed @TransactionAttribute from Bean B, then the OOM does not occur anymore.


              So the question is why is that? I thought the transaction can be propagated from Bean A to B even both beans are annotated as transaction required? Don't they share the same transaction context?


              These two beans looks up (instead of injecting) entity manager from an entity manager factory (jndi lookup emf first, then emf.createEntityManager()). These beans are not declared as session bean and no SMPC is used..


              Can anybody explain to me? If I don't annotate Bean B as transaction required, then what if I want directly to use B without going through A?


              Thanks.

              • 4. Re: Seam 3 transaction 3.0.0.Final possible memory leaks?
                Jason Porter Master

                Please create a JIRA with this information.