Describe the bug
During a load test, the application presents a progressive memory increase leading to instability and eventual restart of the container. The behavior is consistent with a potential memory leak under concurrent workload.
The issue occurs in a macOS environment running the application via Docker. No explicit resource limits (CPU or memory) are configured for the container.
To Reproduce
Steps to reproduce the behavior:
- See attached files;
- Run the application on macOS using Docker
- Execute a load test using Locust with 100 concurrent users
- Keep the test running for a sustained period
- Observe memory consumption and container behavior
Expected behavior
The application should handle concurrent requests without unbounded memory growth, maintaining stability during sustained load without restarting.
Actual behavior
- Memory usage increases progressively during the load test
- After some time, the application becomes unresponsive
- The container stops and restarts automatically
- No memory or CPU limits are configured in Docker, yet the issue still occurs
Additional context
- Environment: macOS + Docker
- Load test tool: Locust (100 concurrent users)
- Attached files include scenarios to reproduce the issue
- The problem may be related to resource exhaustion (hypothesis), particularly JDBC connections, as indicated by the logs below
- The same teset was executed with camunda 7.24 and under same config the memory was stabilished in ~900 Mib
Logs
2026-04-16T19:19:45.275Z INFO 68 --- [io-8080-exec-80] org.operaton.bpm.engine.bpmn.behavior : ENGINE-02001 Execution with id 'Event_14e2i6h' throws an error event with errorCode 'DONE' and errorMessage 'null', but no catching boundary event was defined. Execution is ended (none end event semantics).
/operaton/internal/run.sh: line 153: 68 Killed "$JAVA" -Dloader.path="$classPath" -Doperaton.deploymentDir="$DEPLOYMENT_DIR" $JAVA_OPTS -jar "$BASEDIR/operaton-bpm.jar" --spring.config.location=file:"$configuration"
wait-for-it.sh: waiting 120 seconds for postgres:5432
wait-for-it.sh: postgres:5432 is available after 0 seconds
postgres:5432 available
Setting JAVA property to /usr/lib/jvm/java-17-openjdk/bin/java
Java version is 17.0.18
JAVA_OPTS: -XX:+UseContainerSupport -XX:MaxRAMPercentage=75 -XX:InitialRAMPercentage=35 -XX:+UseG1GC -Djava.security.egd=file:/dev/./urandom
REST API enabled
WebApps enabled
Invoice Example included - needs to be enabled in application configuration as well
classpath: /operaton/internal/webapps/,/operaton/internal/rest/,/operaton/internal/example,/operaton/configuration/userlib/,/operaton/configuration/keystore/
_/_/ _/
_/ _/ _/_/_/ _/_/ _/ _/_/ _/_/_/ _/_/_/_/ _/_/ _/_/_/
_/ _/ _/ _/ _/_/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/ _/_/ _/ _/
_/
_/
Spring-Boot: (v4.0.4)
Operaton: (v2.0.0)
2026-04-16T19:19:48.033Z INFO 68 --- [ main] org.operaton.bpm.run.OperatonApp : Starting OperatonApp v2.0.0 using Java 17.0.18 with PID 68 (/operaton/internal/operaton-bpm.jar started by operaton in /operaton)
2026-04-16T19:19:48.035Z INFO 68 --- [ main] org.operaton.bpm.run.OperatonApp : No active profile set, falling back to 1 default profile: "default"
2026-04-16T19:19:49.011Z INFO 68 --- [ main] o.s.boot.tomcat.TomcatWebServer : Tomcat initialized with port 8080 (http)
2026-04-16T19:19:49.018Z INFO 68 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
Attached files
operaton.zip
bpmn-files.zip
Describe the bug
During a load test, the application presents a progressive memory increase leading to instability and eventual restart of the container. The behavior is consistent with a potential memory leak under concurrent workload.
The issue occurs in a macOS environment running the application via Docker. No explicit resource limits (CPU or memory) are configured for the container.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The application should handle concurrent requests without unbounded memory growth, maintaining stability during sustained load without restarting.
Actual behavior
Additional context
Logs
Attached files
operaton.zip
bpmn-files.zip