Java heap memory error within a test suite

Camunda 7 Topics Discussion & Questions
1

Hi! I’m writing bpm tests and getting an error:

 java.lang.OutOfMemoryError: Java heap space

Within the entire test suite, there are 10 bpm tests, with 100+ cases total. The test suite runs through each process and making assertions against the processes using the BPMNAwareTests library. After some heap dumps, I’ve found that the setup was fine, but the tear down is not.

I’ve set up my tests like so:

beforeSpec {
        init(processEngine)
    }

I’m tearing down in this fashion to no avail:

afterSpec {
        processEngine.close()
        reset()
    }

For ref, I am using Camunda + Kotlin + Micronaut’s Kotest Library.
Initial gradle Daemon settings: -Xms256m –Xmx512m
Gradle test executor settings: Xmx512m
org.gradle.wrapper.GradleWrapperMain test: -Xmx64m -Xms64m.

When using this above tear-down, heap usage went from ~400MB to just under ~200 so there’s progress, although it still hangs and runs out of memory. Using the dominator tree in Eclipse memory analyzer, I can see that there’s some org.apache.ibatis.session.defaults.DefaultSqlSessionFactory that takes up double digit percentage of my bytes available.

Is there a way to manage sessions or to properly tear down the engines within a test suite this large?

2 Likes
2

Hi, I’m getting the same issue. Have you found some solution? Please, share if you know. Thank you in advance.

3

The java.lang.OutOfMemoryError: Java heap space you are experiencing actually indicates that your application is exhausted with the allocated memory in the Java heap.This is usually caused by objects not being fully released between tests. In large Camunda BPM test suites, we generally think calling processEngine.close() in afterSpec will clean up the internal resources. But simply calling processEngine.close() in afterSpec is often not sufficient to clean up all internal resources. While you observed heap usage dropping from around 400 MB to 200 MB after teardown, the remaining retained memory indicates that possibly static references within the Camunda engine are still being held in memory.

You can create and destroy the processEngine per test or at least per test class. This will actually set boundaries for the garbage collector to clear objects and prevent long-lived references from persisting across the entire suite. Additionally, MyBatis caching can significantly contribute to retained heap usage.

To learn more interesting details about the OutOfMemoryError: Java heap space error, you can check out this blog,“How to Solve OutOfMemoryError: Java heap space”. This will give you more insights about this Java Heap Space error.