L2 Cache appears to be enabled in the docker image

[hostalp]

We're running DT 4.12.7 from the docker image (dependencytrack/apiserver:latest in the case of API Server) and we're frequently hitting the container memory limit which causes it to be killed by the OS and then restarted.

Note: Shortly before hitting that limit the JVM ends up spending most of the CPU time running GC cycles in a loop which makes the instance unusable. I doesn't however throw an OutOfMemoryError and keeps running in this state until it hits the container limit and is killed. Even increasing the container memory limit together with decreasing the MaxRAMPercentage JVM setting (as low as 60.0) doesn't change that.

After few increases of the memory limit which didn't help, we ended up collecting & analyzing the heap dump (we had to add the JDK into the container in order to use jmap) to find out that the largest object is org.datanucleus.cache.SoftLevel2Cache which takes almost 8 GB - which looks pretty much like #3225 where there was (in Nov 2023) stated that the L2 cache would be disabled by default in future releases.

When looking at https://github.com/DependencyTrack/dependency-track/blob/master/src/main/resources/application.properties, the L2 cache does indeed appear to be disabled there: alpine.datanucleus.cache.level2.type=none

However in /opt/owasp/dependency-track/dependency-track-apiserver.jar:WEB-INF/classes/application.properties (inside the above mentioned container image) there's just # alpine.datanucleus.cache.level2.type= which probably means that the cache is enabled (if not disabled elsewhere which doesn't appear to be the case). Is that really correct?

Note: We're going to try the "weak" L2 cache type which should use weak references for its objects. If that doesn't help, we'll try "none".

[nscuro]

The code you linked is in master and was not released as part of 4.12.x. It will be part of 4.13.0 which is to be released today.

[hostalp]

Thanks for the clarification. Since the comment about disabling the L2 cache was written quite a long time ago, I optimistically expected it to be already disabled. 😊

By the way, the weak L2 cache type looks promising. It looks like in the Parallel GC mode, most of these weak references are collected during full GCs which means that the cache may be still of some use. In the G1 GC mode the cache appears to be cleared more frequently, this collector is probably more aggressive towards the weak references.
I didn't compare the performance between the weak and none settings, but if the cache is of some help, the weak mode should perform better and is therefore worth the increased memory consumption. Yes, I saw #4305 where the collected stats show its poor efficiency, so it may be not worth it actually.