[
https://issues.jboss.org/browse/SOLDER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603811#comment-12603811
]
Stuart Douglas commented on SOLDER-106:
---------------------------------------
Can you upgrade you weld version to the latest version of weld and see if you
still have this problem?
It looks like your problem is with @Dependent scoped bean instances that have a
circular dependency, the lastest weld will detect this and throw a deployment
error, instead of just running out of memory.
> Seam transaction potential memory leaks if there is nested
> @TransactionAttritue
> -------------------------------------------------------------------------------
>
> Key: SOLDER-106
> URL: https://issues.jboss.org/browse/SOLDER-106
> Project: Seam Solder
> Issue Type: Bug
> Affects Versions: 3.0.0.Final
> Environment: Windows, Eclipse, jboss AS 6 Final
> Reporter: yangju
>
> 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
_______________________________________________
seam-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-issues
