bellsoft-liberica | Cloud Native Buildpack that provides the Bellsoft Liberica

So what exactly is the problem here? Without knowing more about the application, I can't really tell why it's trying localhost first, but it seems like it's able to connect to mongo running on the person-db container after that based on these logs:

OK, so here's what this is telling us:

Calculating JVM memory based on 274300K available memory

The memory calculator is detecting a maximum amount of memory available in the container as 274300KB, or about 274M.

fixed memory regions require 662096K which is greater than 274300K available for allocation: -XX:MaxDirectMemorySize=10M, -XX:MaxMetaspaceSize=150096K, -XX:ReservedCodeCacheSize=240M, -Xss1M * 250 threads

This message is saying that the memory calculator needs at least 662096KB or 662M in its present configuration.

It's also breaking down why it needs/wants that much:

• 10M for direct memory
• 150096K for metaspace
• 240M for reserved code cache
• 250M for threads (thread stack specifically)

That's not counting the heap which will require more (you seem to want at least 1G for the heap).

This leaves two possibilities:

1. The container is not provisioned large enough. You need to give it more memory.
2. The memory calculator is not correctly detecting the memory limit.

If you suspect #2, look at the following. The memory calculator selects it's max memory limit (i.e. the 274M in the example above) by looking in these places in this order.

1. Check the configured container memory limit by looking at /sys/fs/cgroup/memory/memory.limit_in_bytes inside the container.
2. Check the system's max available memory by looking at /proc/meminfo and the MemAvailable metric, again, from inside the container.
3. If all else fails, it'll end up with a 1G fallback.

If it's truly not working as described above, please open a bug and provide as much detail as you can.

Alternatively, you may tune the memory calculator. You can instruct it to give less memory to specific regions such that you reduce the total memory required to be less than the max available memory.

You can do that by setting the JVM memory flags in the JAVA_TOOL_OPTIONS env variable (you have BPE_JAVA_TOOL_OPTIONS which isn't right). See https://paketo.io/docs/buildpacks/language-family-buildpacks/java/#runtime-jvm-configuration.

For example, if you want to override the heap size then set -Xmx in JAVA_TOOL_OPTIONS to something custom. The memory calculator will see what you've set and adjust the remaining memory settings accordingly. Override as many as necessary.

To get things down to fit within 274M of RAM, you'd have to go really small. Something like -Xss256K -XX:ReservedCodeCacheSize=64M -XX:MaxMetaspaceSize=64 -Xmx64M. I didn't test to confirm, but this shows the idea of what you need to do. Reduce the memory settings such that the sum total all fits within your max memory limit for the container.

This also does not take into account if your application will actually be able to run within such small limits. If you go too small you may at some point see OutOfMemoryErrors or StackOverflowErrors, and your app will crash. You can also negatively impact performance by reducing code cache size too much since this is where the JIT stores byte code that it's optimized to native code. You could even cause GC issues, or degraded performance due to too much GC if the heap isn't sized right. In short, be very careful if you're going to do this.

It depends on your goal here. It sounds like you want to change the max direct memory in your container when your app runs so you should be just doing what you indicated works here (and what's listed in the docs).

docker run -e JAVA_TOOL_OPTIONS=-XX:MaxDirectMemorySize=64M docker.io/example/app-name:0.0.1

The doc link you're referencing is talking about configuring options at runtime which is what you are doing with the env variables.

According to the docs:

Paketo Buildpacks may download dependencies from the internet. For example, the Java Buildpack will download the BellSoft Liberica JRE from the Liberica github releases by default. If a dependency URI is inaccessible from the build environment, a binding can be used to map a new URI to a given dependency.

For now configuring bindings isn't possible using the spring-boot-maven-plugin (or the Gradle plugin). Therefore we need to switch over to pack CLI.

=== Use pack CLI with bindings to configure a different JDK download uri ===

The pack docs tell us about the general layout of a binding directory (/platform/bindings is later created inside the pack build container):