Project

General

Profile

Actions

bug #7900

closed

Excessive heap consuption in RegistrationWorkingsetEditor with big workingsets

Added by Andreas Kohlbecker about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Highest
Category:
cdm-vaadin
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
blocker
Found in Version:
Tags:

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

(Allocations of Teams - fist number in Table is the object count

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.


Files

stacktrace.png (99.8 KB) stacktrace.png Andreas Kohlbecker, 11/09/2018 12:30 PM
mem-diff-2.png (47.2 KB) mem-diff-2.png Andreas Kohlbecker, 11/09/2018 12:36 PM
mem-diff-1.png (52.7 KB) mem-diff-1.png Andreas Kohlbecker, 11/09/2018 12:41 PM
mem-diff-1-2.png (45.7 KB) mem-diff-1-2.png Andreas Kohlbecker, 11/09/2018 12:44 PM
Allocations-of-Teams.png (92.9 KB) Allocations-of-Teams.png Andreas Kohlbecker, 11/12/2018 11:28 AM
mem-getCollectorAndFieldNumber.png (33.5 KB) mem-getCollectorAndFieldNumber.png Andreas Kohlbecker, 11/12/2018 02:11 PM
mem-getCollectorAndFieldNumberXX.png (20.1 KB) mem-getCollectorAndFieldNumberXX.png Andreas Kohlbecker, 11/12/2018 02:11 PM

Related issues

Copied to EDIT - bug #7904: DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() creates temporary Team objects which can not be garbage collected. ClosedAndreas Müller

Actions
Actions #2

Updated by Andreas Kohlbecker about 4 years ago

Actions #4

Updated by Andreas Kohlbecker about 4 years ago

  • Description updated (diff)
Actions #5

Updated by Andreas Kohlbecker about 4 years ago

Actions #6

Updated by Andreas Kohlbecker about 4 years ago

  • Description updated (diff)
Actions #7

Updated by Andreas Kohlbecker about 4 years ago

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:

Actions #8

Updated by Andreas Kohlbecker about 4 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.

Actions #9

Updated by Andreas Kohlbecker about 4 years ago

  • % Done changed from 20 to 50
Actions #10

Updated by Andreas Kohlbecker about 4 years ago

  • Description updated (diff)
Actions #11

Updated by Andreas Kohlbecker about 4 years ago

  • Status changed from New to Resolved
Actions #12

Updated by Andreas Kohlbecker about 4 years ago

  • Copied to bug #7904: DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() creates temporary Team objects which can not be garbage collected. added
Actions #13

Updated by Andreas Kohlbecker about 4 years ago

The DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() is actually the root cause for the massive memory allocation as pointed out in #7904

Actions #14

Updated by Andreas Kohlbecker about 4 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.

Actions

Also available in: Atom PDF