Repository navigation
Conversation
…ns (eclipse-dirigible#8231) The ENTRYPOINT set no heap sizing, so the JVM capped the heap at 25% of the container limit (256 MB on a 1 GiB container). The default edition exhausted that on the first publish, poisoned its file-backed H2 store, and - never OOM-killed - stayed Up answering 401 to every login, so no restart policy fired. Both Dockerfiles now launch with: - -XX:MaxRAMPercentage=50.0 - doubles the heap ceiling to half the container limit. It is a ceiling, not a reservation, so RSS still only grows with actual heap use; 50% leaves headroom for the GraalVM-heavy default edition's off-heap footprint. Override from the launch for a differently sized container. - -XX:+ExitOnOutOfMemoryError - the JVM exits on heap exhaustion instead of serving requests from a poisoned store, so an orchestrator restarts it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ENTRYPOINT set no heap sizing, so the JVM capped the heap at the container-aware default of 25% of the limit (256 MB on a 1 GiB container). The default edition exhausted that on the first publish (587
OutOfMemoryErrorlines), poisoned its file-backed H2 store, and - never OOM-killed (OOMKilled=false) - stayedUpanswering 401 to every login (including/actuator/healthand/services/core/version), so no restart policy fired. Both editions share this ENTRYPOINT; the Java edition only escaped because it is lighter.Both Dockerfiles now launch with:
-XX:MaxRAMPercentage=50.0- doubles the heap ceiling to half the container limit. It is a ceiling, not a reservation, so RSS still only grows with actual heap use; 50% leaves headroom for the GraalVM-heavy default edition's off-heap footprint (its reported RSS was 754 MiB with the 256 MB heap). Override from the launch for a differently sized container.-XX:+ExitOnOutOfMemoryError- the JVM exits on heap exhaustion instead of serving requests from a poisoned store, so an orchestrator restarts it. (This complements A failed startup never exits the JVM: the terminal's non-daemon ttyd reader threads keep the container Up with no listener, so no restart policy fires #8225, which keeps a failed startup from being held Up by non-daemon ttyd threads.)Verification: the JVM accepts both flags (
java -XX:MaxRAMPercentage=50.0 -XX:+ExitOnOutOfMemoryError -version), and both ENTRYPOINT exec-form arrays remain valid JSON. Thedocker-buildCI job builds both images. I did not build the images or measure heap behavior under a container memory limit locally (no Docker-with-memory-limit in this environment); the exact percentage may warrant tuning against a measured run on a 1 GiB and 768 MiB container.Fixes #8231
🤖 Generated with Claude Code