Project

General

Profile

bug #7900

Excessive heap consuption in RegistrationWorkingsetEditor with big workingsets

Added by Andreas Kohlbecker 5 months ago. Updated about 2 months ago.

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

100%

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.

stacktrace.png View (99.8 KB) Andreas Kohlbecker, 11/09/2018 12:30 PM

mem-diff-2.png View (47.2 KB) Andreas Kohlbecker, 11/09/2018 12:36 PM

mem-diff-1.png View (52.7 KB) Andreas Kohlbecker, 11/09/2018 12:41 PM

mem-diff-1-2.png View (45.7 KB) Andreas Kohlbecker, 11/09/2018 12:44 PM

Allocations-of-Teams.png View (92.9 KB) Andreas Kohlbecker, 11/12/2018 11:28 AM

mem-getCollectorAndFieldNumber.png View (33.5 KB) Andreas Kohlbecker, 11/12/2018 02:11 PM

mem-getCollectorAndFieldNumberXX.png View (20.1 KB) 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. Feedback 11/13/2018

Associated revisions

Revision 07bbd695 (diff)
Added by Andreas Kohlbecker 4 months ago

ref #7900 comitting writable transaction before loading the registration working set

Revision 4d18f3c4 (diff)
Added by Andreas Kohlbecker 4 months ago

ref #7900 read-only transactions in DTO service with Propagation.REQUIRES_NEW

Revision 923fd553 (diff)
Added by Andreas Kohlbecker 4 months ago

ref #7900 reverting : read-only transactions in DTO service with Propagation.REQUIRES_NEW

Revision f277df8a (diff)
Added by Andreas Kohlbecker 4 months ago

ref #7900 removing remains from old code

History

#1 Updated by Andreas Kohlbecker 5 months ago

#2 Updated by Andreas Kohlbecker 5 months ago

#3 Updated by Andreas Kohlbecker 5 months ago

#4 Updated by Andreas Kohlbecker 5 months ago

  • Description updated (diff)

#5 Updated by Andreas Kohlbecker 4 months ago

#6 Updated by Andreas Kohlbecker 4 months ago

  • Description updated (diff)

#7 Updated by Andreas Kohlbecker 4 months 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:

#8 Updated by Andreas Kohlbecker 4 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 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 4 months ago

  • % Done changed from 20 to 50

#10 Updated by Andreas Kohlbecker 4 months ago

  • Description updated (diff)

#11 Updated by Andreas Kohlbecker 4 months ago

  • Status changed from New to Resolved

#12 Updated by Andreas Kohlbecker 4 months ago

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

#13 Updated by Andreas Kohlbecker 4 months ago

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

#14 Updated by Andreas Kohlbecker about 2 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 50 to 100

the symptom as described in this issue is no longer reproducible.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)