This seems to slowly fill up memory, but it is taking some time

(dotimes [i 4] (doto (Thread. (fn [] (dotimes [i 1000000000] (.intern (str (java.util.UUID/randomUUID)))))) .start))

(throw (new java.lang.OutOfMemoryError "Ahh"))

hmmm not a bad idea I guess 😃

or just (throw (new OutOfMemoryError "Ahh")) as it's shorter

I will keep this in mind next time it happens and see if this could fulfill the requirement for catching it, I’m guessing that this would do it

(byte-array 1e10)

Thanks for the suggestions! This error sometimes comes up when using #C013B7MQHJQ so I was thinking of a workaround

Why are you trying to catch it?

+1, catching OOM is a bad idea because it means the system is unwell but you just silence it.

Throwing OOM is used to simulate such case only

@U6T7M9DBR Good question! Polylith uses a classloader to load the projects. After X amount of time (hours/days) this error pops up. The only way to recover from this error in this situation is restarting the Polylith shell. As this breaks the flow and also has some heavy startup time, I was thinking of something more user friendly

(btw, this error doesn’t seem to occur for all users of Polylith, but only specifc bigger projects it seems)

My idea would be to wrap the try/catch around this classloader part specifically

And maybe another important part of my idea would be is that I would destroy the process when this happens, and start a new one 🙂

More specifically, the process would be managed by another babashka process (through pods). This process needs to be told through the bencode format that something bad happened. I think now I’ve explained all the parts of my idea 😅

Just crash the jvm and have something else restart it

I don’t think you have any guarantees after a OOM error

It’s an internal VM error, so recovering probably works most of the time but is not reliable.

Which JVM version are you using?

Right now

java version "11.0.7" 2020-04-14 LTS

You can analyse the root cause of the OOM from a heap dump if you’d like. The metaspace memory is inspectable after that as well. It sounds like something is not being garbage collected correctly, or you need more memory

Yeah you are probably right. Unfortunately, it is not happening too often to find it easily, but often enough that it is annoying

We usually run -XX:+HeapDumpOnOutOfMemoryError

I will add that to the polylith profile and wait for the next time. Thanks!

@U0FT7SRLP If it happens again, you can take a heap snapshot manually by doing this in the terminal:

jmap -dump:live,format=b,file=heapdump.bin 12312

Nice! Thanks