-
-
Notifications
You must be signed in to change notification settings - Fork 190
Description
Describe the bug
I was able to reproduce the memory leak using the original dataset provided by @dariok. With enough resources, about 10 GB of RAM, the process did finish successfully. After restoring the entire dataset of 35 GB, containing 26874 XML files (including .html, .xsl, .svg), almost 5 GB of RAM retained.

There is ~59000 instances of TriggerStatePerThread$TriggerState
. Since I can see that there is two instances for each restored item that is ~29500 CREATE_DOCUMENT
triggers - one for BEFORE
and for the AFTER
phase.

I was then wondering whether I was missing +3000 documents until I discovered that CREATE_COLLECTION
was also invoked:

With the collection.xconf
as it is in the issue description (without any triggers configured) the outcome was very different. RAM usage stayed within reasonable bounds (<2 GB) and all memory was freed afterwards (see screenshot).

My analysis indicates that TriggerStates are held in memory indefinitely and are the cause of the leak. This is especially interesting as the events that were triggered are not the ones that are defined and thus one would not expect them to be fired at all.
References
Expected behavior
XQueryTriggerStates to be removed from memory once the trigger is done.
To Reproduce
If the above isn't working, please tell us the exact steps you took when you encountered the problem:
full-backup-restore-with-triggers.zip
- start a clean instance of exist-db v6.2.0 with a profiler attached
- restore the backup in the attached zip
- the backup finishes
- in the Profiler you should be able to find XqueryTriggerState instances that retain in memory
Screenshots
see above
Context
- Build: eXist-6.2.0
- Java: 1.8.0_352
- OS: Mac OS X 14.5
Additional context
- How is eXist-db installed? built from source
- Any custom changes in e.g.
conf.xml
? none