Open m-kotzyba opened 3 years ago
Thanks for reporting an apparent memory leak. That is something we should investigate. However, higher-level processes should actually have no tasks at all, so this also shows that something is going wrong during the process migration (see #3307). I want to suggest that this issue focus on the memory leak.
I suspect that the large amount of memory is acquired by Hibernate, as it loads objects dynamically (so-called lazy loading). The objects are loaded the first time they are accessed (here all processes with all their tasks) but are not automatically removed from memory when they are no longer used. There is a question and answer on StackOverflow. But that's only a guess so far.
After looking on this from the distance, I don’t think this is a memory leak. Java does allocate memory, as long as the limit (-Xmx
) isn’t yet reached. If the limit is reached, the garbage collector is run, to remove no longer used objects from memory, but the memory is not compacted or freed again. It will remain occupied as long as the JVM lives. This is the default behaviour of Java. The JVM will then use the free parts of the memory to create objects again, until it is full, then run the garbage collection again, and so on.
If there was a memory leak, doing this operation again and again would lead to an out of memory error. But I did never hear that this happened to anybody, so we can quite safely assume that there is no memory leak.
You are right, I indeed never experienced a classic "out of memory error" and hence, it may not be a memory leak. However, as far as I remember, when the majority of the memory was occupied by the system, the task to "change the status of multiple processes" took very long and I had to restart the system in the meantime.
Selecting multiple processes and changing their status (via "Mögliche Aktionen" --> "Bearbeitungsstatus runtersetzen") allocates a lot of memory over time and do not deallocates it in the end:
Before:![001](https://user-images.githubusercontent.com/85474095/129029478-acee9ded-8626-430a-ab58-5177ba25579b.PNG)
Afterwards:![002](https://user-images.githubusercontent.com/85474095/129029506-7be72c6a-6f9c-4885-9c4b-8c6cc488b220.PNG)
Scenario context: During Migration (Kitodo 2.X --> 3.3) and the included generation of "Übergeordnete Vorgänge", several "Übergeordnete Vorgänge" have processes which are all finished. To trigger the status finished also for these "Übergeordnete Vorgänge", the status of at least one of its "untergeordnete Vorgänge" has to set down and up afterwards. While this issue is solved in Kitodo 3.3.1, the memory leak still exists.