Excessive heap consuption in RegistrationWorkingsetEditor with big workingsets
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
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.
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
#7 Updated by Andreas Kohlbecker 10 months 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 10 months 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
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.