]
yangju commented on SEAMPERSIST-50:
-----------------------------------
Is there any documentation on how to upgrade weld deployer in jboss 6? I can guess it but
not sure it would be correct. For example, I can replace weld-core-no-jsf.jar with the
latest weld-core.jar but what about other jars such as weld-int-ejb.jar and weld-spi.jar?
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
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: