[seam-issues] [JBoss JIRA] Resolved: (SEAMPERSIST-50) Seam transaction potential memory leaks if there is nested @TransactionAttritue

[Stuart Douglas (JIRA)]

     [ https://issues.jboss.org/browse/SEAMPERSIST-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved SEAMPERSIST-50.
---------------------------------------

         Assignee: Stuart Douglas
    Fix Version/s: 3.0.1.CR1
       Resolution: Done


I have fixed some memory leaks to do with using Instance<>, if you still have problems please file a new issue with details.

> Seam transaction potential memory leaks if there is nested @TransactionAttritue
> -------------------------------------------------------------------------------
>
>                 Key: SEAMPERSIST-50
>                 URL: https://issues.jboss.org/browse/SEAMPERSIST-50
>             Project: Seam Persistence
>          Issue Type: Bug
>    Affects Versions: 3.0.0.Final
>         Environment: Windows, Eclipse, jboss AS 6 Final
>            Reporter: yangju
>            Assignee: Stuart Douglas
>             Fix For: 3.0.1.CR1
>
>
> I have been doing some performance testing on cdi beans with @TransactionAttribute in jboss AS 6 final. After my application runs non-stop for a while (I have created 10 threads constantly invoking the ApplicaitonScoped bean to get data from database and then update those data), I got got exception:: java.lang.OutOfMemoryError: GC overhead limit exceeded.
> This happened when I have Bean A injects Bean B and both A and B are annotated with @TransactionAttribute.
> 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. I thought transaction will be propagated from one bean to another, or it only does that for stateful session beans or SMPC? If I remove one of the TransactionAttribute annotation from B then the OOM problem does not occur.
> This OOM problem also occurs after my application runs for a while in this scenario:
> Bean A injects Bean B and Bean C; Bean C injects Bean B.
> I analyzed the heap dump with eclipse memory analyzer and it suspects that the seam 3 transaction interceptor might have memory leaks.
> I used Eclipse Memory Analyzer to analyze the heap dump when OOM occurred. It says:
> 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>".
> 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 
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira