OutOfMemoryError from JTASynchronizationListener [message #1003426] |
Mon, 21 January 2013 08:10 |
Uwe Oetken Messages: 4 Registered: January 2013 |
Junior Member |
|
|
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 #1004099 is a reply to message #1003426] |
Tue, 22 January 2013 15:19 |
|
Odd, what is different between the development and production servers?
What is WebSphere is holding onto the old transaction? Or is this the current transaction? Does it read a lot of objects?
WebSphere does do some sort of caching of EntityManagers in its EJB support, this may be related to the issue, although it should be clearing them to avoid such issues.
Are you encountering any failed transactions or errors, it could be an issue that things are not getting properly cleaned up for failed transactions.
James : Wiki : Book : Blog : Twitter
|
|
|
|
|
Re: OutOfMemoryError from JTASynchronizationListener [message #1005131 is a reply to message #1004560] |
Thu, 24 January 2013 14:31 |
|
Could you try removing the composite persistence unit to see if it has any affect. Both of your persistence units are using the same database/data-source, so there is no reason to be using a composite persistence unit.
Also note that,
<property name="eclipselink.jdbc.cache-statements" value="true" />
has no real affect when using a DataSource, you need to enable statement caching in the data-source config, not in EclipseLink (this is only relevant when using EclipseLink connection pooling).
James : Wiki : Book : Blog : Twitter
|
|
|
|
Powered by
FUDForum. Page generated in 0.03605 seconds