| OutOfMemoryError from JTASynchronizationListener [message #1003426] |
Mon, 21 January 2013 03:10  |
Eclipse User |
|
|
|
Hello everybody,
50 minutes after application start out server is running out of memory.
HeapDump shows that there is a JTASynchronizationListener holding over 93 percent of memory.
Several use cases have been successfully executed until this, none of them seems to cause the problem. The used heap memory rises 35 minutes after application start from normal level (~ 200 MByte) up to 1.5 GByte and could not get garbage collected any more.
Environment is WebSphere 6.1 Fixpack 45 with EJB 3.0 Feature pack, Eclipselink 2.3.0 with JPA 1.0
EclipseLink shared cache is disabled via persistence.xml, class specific cache in descriptors have default values SOFT_CACHE.
This problem occures non deterministic on productive instances and could not be seen in development instances after running some thousands of use cases.
HeapDump shows:
JTASynchronizationListener with size of 1.4 GByte references RepeatableWriteUnitOfWork. Inside this there is an UnitOfWorkChangeSet, containing an IdentityHashMap with more than 151.000 entity objects of different classes (packages .../core/server/..., see below). Some of these entities will never be modified by the application. It seems as if these objects could not have been read in an single transaction.
There are 9 other instances of JTASynchronizationListener with heap size between 40 bytes and 8.8 MBytes, they seem to be okay.
Is looks like this UnitOfWorkChangeSet collects objects from a lot of transactions and is not cleaned up after transactions ended.
Here is the reference tree from IBM HeapAnalyzer:
1.421.397.360 (93,37%) [296] 16 com/ibm/ejs/j2c/MCWrapper 0x9caa10f8
1.418.944.768 (93,2%) [224] 7 com/ibm/ws/Transaction/JTA/TransactionImpl 0xa6c80f40
1.418.943.264 (93,2%) [40] 2 com/ibm/ws/Transaction/JTA/RegisteredSyncs 0xa500bae0
1.418.943.224 (93,2%) [32] 2 array of java/util/ArrayList 0xa494cfb0
1.418.942.056 (93,2%) [24] 1 java/util/ArrayList 0xa494ed20
1.418.942.032 (93,2%) [56] 3 array of java/lang/Object 0xa494fd70
1.418.593.048 (93,18%) [40] 5 org/eclipse/persistence/transaction/JTASynchronizationListener 0xa49513f8
1.412.911.600 (92,81%) [392] 16 org/eclipse/persistence/internal/sessions/RepeatableWriteUnitOfWork 0xa6c8a598
1.376.790.656 (90,44%) [56] 7 org/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet 0xa6f56fa8
1.376.767.904 (90,43%) [40] 1 java/util/IdentityHashMap 0xa6f57190
1.376.767.864 (90,43%) [1.040] 164 array of java/lang/Object 0xc4359110
21.540.832 (1,41%) [112] 6 org/eclipse/persistence/internal/sessions/ObjectChangeSet 0x9abdda68
21.540.520 (1,41%) [56] 6 org/eclipse/persistence/internal/sessions/UnitOfWorkChangeSet 0x9b592c10
20.491.184 (1,35%) [40] 1 java/util/IdentityHashMap 0x9b5f47a8
20.491.144 (1,35%) [1.048.592] 151.462 array of java/lang/Object 0x9ed38758
4.760 (0%) [112] 6 .../core/server/fzg/bo/MarVO 0xa73cce78
1.352 (0%) [112] .../core/server/fzg/bo/MarVO 0xa738cd58
912 (0%) [112] 6 .../core/server/fzg/bo/MarVO 0xa72cad38
544 (0%) [96] 6 .../core/server/util/bo/KlaVO 0xa71cc700
528 (0%) [96] 6 .../core/server/util/bo/KlaVO 0xa8e0f9b0
528 (0%) [104] .../core/server/st/bo/DiaVO 0xa73cd188
528 (0%) [96] 6 .../core/server/util/bo/KlaVO 0xa73ccff0
...
Why these entities are still referenced? How can I avoid this?
Thanks for help,
Uwe
|
|
|
|
|
|
|
|
| Re: OutOfMemoryError from JTASynchronizationListener [message #1007567 is a reply to message #1005131] |
Wed, 06 February 2013 09:06  |
| Eclipse User |
|
|
|
Hello James,
thanks very much for your suggestions.
I think we found the errors:
1. There are some methods in the session beans implemented by a super class:
public abstract class BaseStatelessSessionBean {
public MyObject[] findSomething() {
...
}
}
@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class MyStatelessSessionBean extends BaseStatelessSessionBean {
public MyObject[] findOther() {
...
}
}
This super class does not get the default J2EE transaction attributes from the derived session bean as expected. So calls to findOther() run with J2EE transaction attribute NOT_SUPPORTED from session bean, but calls to findSomething() run with J2EE transaction attribute REQUIRED. So it has an transaction, and Eclipselink flushes the result of every former read query from the ejb call to the RepeatableWriteUnitOfWork (see performPreQueryFlush() in executeReadQuery() at class org.eclipse.persistence.internal.jpa. EJBQueryImpl).
With explicit J2EE transaction attributes at session bean methods from super class the application runs with heap usage between 0.4 and 0.8 GByte vs. 1.1 to 1.5 GByte before.
2. These super class methods are called in production, but not in development, because they implement generic compression of the results to save network load on WAN communication. That's why this problem could not be identified in development.
3. Additional: Compound persistence units seem to consume more memory and processor runtime than single persistence units as we use now. Indeed, they are here not really required, they only existed for better code organization (enlisting of > 300 entities at their specific ejb project). Without compound persistence units the application's standard test cases run 42 minutes vs. 52 minutes before.
4. And XA transactions are expensive, and we can go without until now.
|
|
|
Powered by
FUDForum. Page generated in 0.03537 seconds
Home