JBP does not honor '-XX:MaxDirectMemorySize=0' option

[imod]

Because the new elasticsearch 'Java High Level REST Client' uses the 'direct buffer memory' and we have quite memory heavy search requests, we need to disable the direct memory calculation by the JBP and hand over the control back to the JVM. There is a more detailed description of the problem at [1].

So we tried to disable the calculated setting with -XX:MaxDirectMemorySize=0 and tried the following JAVA_OPTS:

-XX:+PrintFlagsFinal -XX:MaxDirectMemorySize=0 -Djava.security.egd=file:///dev/urandom

This will print all JVM flags with there actual used value and this reveals that it still uses the calculated value by the JBP (10M in this case):

2018-05-05T08:48:18.42+0200 [APP/PROC/WEB/0] OUT uintx MaxDirectMemorySize := 10485760 {product}

on the other hand, starting it with -XX:MaxDirectMemorySize=20M works fine:

2018-05-05T08:41:55.36+0200 [APP/PROC/WEB/0] OUT uintx MaxDirectMemorySize := 20971520 {product}

btw. setting it to -XX:MaxDirectMemorySize=0M (note the M after the 0) does not make any difference too.

...we currently use JBP https://github.com/cloudfoundry/java-buildpack#v4.10

As this is quite a blocker for us (we now face java.lang.OutOfMemoryError: Direct buffer memory), it would be great if the JBP would support setting MaxDirectMemorySize back to the default, which is 0.

[1] https://discuss.elastic.co/t/direct-buffer-memory-problems-with-resthighlevelclient/106647

[nebhale]

/cc @glyn

[nebhale]

I’m guessing that there might be some parsing problems, but even if this causes runtime issues, I think we should honor the setting of the value.

[glyn]

@nebhale Agreed. It's a simpler contract always to preserve user-specified values, regardless of whether these will work well.

[nebhale]

@imod Memory Calculator v3.13.0.RELEASE is available to online buildpacks now and will go out in the next release of the buildpack.

[imod]

@nebhale many thanks!