vmext-demo.wmflabs.org seems to die frequently

[AndreG-P]

According to the log file it seems to be a memory problem.

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "http-nio-8080-ClientPoller-1"

@vstange might that be related to the spring framework?

[physikerwelt]

@vstange is it possible to add something along the lines of https://stackoverflow.com/a/13119689/9215209 as a fallback?

[vstange]

sure, this needs to be set as an environment variable. so whatever calls java [vm options] -jar ...jar needs to add it.

@AndreG-P I doubt that this is spring related. More likely we have a creeping memory leak. Setting the proposed vm option for HeapDumpOnOutOfMemoryError and HeapDumpPath

[AndreG-P]

I figured out that I created for each CAS translation request a new translator object. That messes up the memory because the init process for the translators uses a lot of java reflections. I changed this behavior now and only use two "final" translator objects. That should solve the problem.

@physikerwelt However, since we are running more often into memory problems on drmf-beta, we probably should add the suggested flag HeapDumpOnOutOfMemoryError?

[AndreG-P]

@vstange It's probably good to add the HeapDumpOnOutOfMemoryError as you suggested. However, vmext-demo will be started as a service on drmf-beta. Do you know how I can configure the service (the name is mathpipeline by the way) to use this flag when it starts the jar?

[AndreG-P]

@physikerwelt If I remember it correctly, the memory issue is originated here:

https://github.com/ag-gipp/vmext-demo/blob/fa3d50ac5de720fd88bc6c48cc5ab321a750a247/src/main/java/org/citeplag/controller/MediaController.java#L45-L46

We can simply replace the maps with a cache map. Java 8 brings the WeakHashMap (Baeldung Guide). Or we use Guava (already included in the project) with the CacheBuilder (Baeldung Guide).

According to our latest Skype discussion, you may don't like to use a cache at all. So I will wait for your feedback before I implement this.

[physikerwelt]

I am not entirely sure, if we talk about the same thing. Cache as something that does not need to persistent is ok. I was under the impression that we aim to cache something that needs to be in memory forever. This would not be optimal.

@AndreG-P does that answer you question?

[AndreG-P]

@physikerwelt Just to make sure I understand you correctly. You want to a cache solution that survives a JVM restart, right? In that case we need a database in the background or manually read/write our maps to disks. MapDB seems to be the right option. As shown in this small code snippet, it seems to be quite easy to use with Java Maps (or other collections)

//import org.mapdb.*
DB db = DBMaker.memoryDB().make();
ConcurrentMap map = db.hashMap("map").make();
map.put("something", "here");