bug #7900
Excessive heap consuption in RegistrationWorkingsetEditor with big workingsets
100%
Description
Adding a new name to the registration workingset Kulikovskiy, M., Lange-Bertalot, H., Metzeltin, D. & al. - Lake Baikal: Hotspot of endemic diatoms I. in Taxonomy - biogeography - diversity. 23. (http://api.cybertaxonomy.org/phycobank/app/registration#!workingset/5d29277e-a527-4a26-8685-1a7a6cb2e3de) fails on the production server due to excessive heap consumption after pressing the save button in the name editor.
The problem happens after the name is saved during the reloading of the workingset:
A differential comparison of the heap before and during the reloading of the workingset shows that especially the amount Team objects is increasing excessively.
1 minute after saving +25.000 Team objects
3 minutes after saving +109.000 Team objects
Comparing the objects in memory from 3 minutes and 1 minute after saving reveals that only the amount of Team objects is increasing that much!
The allocation analysis shows that all Team Objects have been created in the call to the RegistrationWorkinsetService
There are 423 Teams in the database but in the test above more than 100.000 Team objects have been created evene after 3 minutes.
Related issues
Associated revisions
ref #7900 comitting writable transaction before loading the registration working set
ref #7900 read-only transactions in DTO service with Propagation.REQUIRES_NEW
ref #7900 reverting : read-only transactions in DTO service with Propagation.REQUIRES_NEW
ref #7900 removing remains from old code
History
#1 Updated by Andreas Kohlbecker almost 3 years ago
- File mem-diff-2.png View added
#2 Updated by Andreas Kohlbecker almost 3 years ago
- File mem-diff-1.png View added
- Description updated (diff)
#3 Updated by Andreas Kohlbecker almost 3 years ago
- File mem-diff-1-2.png View added
#4 Updated by Andreas Kohlbecker almost 3 years ago
- Description updated (diff)
#5 Updated by Andreas Kohlbecker almost 3 years ago
- File Allocations-of-Teams.png View added
- Description updated (diff)
#6 Updated by Andreas Kohlbecker almost 3 years ago
- Description updated (diff)
#7 Updated by Andreas Kohlbecker almost 3 years ago
- File mem-getCollectorAndFieldNumber.png View added
- File mem-getCollectorAndFieldNumberXX.png View added
It seems as if the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() is causing the massive memory usage. In this method new Team instances are created. Replacing this method by a empy implementation which only returns an empty string solves at least the memory issue:
In contrast to the above graph the getCollectorAndFieldNumber() will create a massive load of Teams which can not be garbage collected:
#8 Updated by Andreas Kohlbecker almost 3 years ago
- % Done changed from 0 to 20
The root cause for the problem is the RegistrationWorkingsetPresenter.onDoneWithTaxonnameEditor() method in which a write enabled transaction is committed at the wrong time. The commit takes place after reloading the registration workingset which causes the whole workingset to be reloaded in the writable transaction since the RegistrationWorkingSetService misses the transaction propagation type being set to Propagation.REQUIRES_NEW in @Transactional(readOnly=true). With REQUIRES_NEW a new read-only transaction would be created even if the service is called in a writable transaction.
Despite having pinned down the root cause to these two findings it is still quite irritating that the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() can impose such a massive load on the heap even if it is only returning plain strings.
#9 Updated by Andreas Kohlbecker almost 3 years ago
- % Done changed from 20 to 50
#10 Updated by Andreas Kohlbecker almost 3 years ago
- Description updated (diff)
#11 Updated by Andreas Kohlbecker almost 3 years ago
- Status changed from New to Resolved
#12 Updated by Andreas Kohlbecker almost 3 years ago
- Copied to bug #7904: DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() creates temporary Team objects which can not be garbage collected. added
#13 Updated by Andreas Kohlbecker almost 3 years ago
The DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() is actually the root cause for the massive memory allocation as pointed out in #7904
#14 Updated by Andreas Kohlbecker over 2 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100
the symptom as described in this issue is no longer reproducible.
