Support env memory overrides to start-tc-server (daggy main)

[akomakom]

Currently -Xms2g -Xmx2g is hardcoded.

There are 3 PRs, a review of just this one is all I need.

[jhouserizer]

In discussion with Gary, we're having second thoughts about this...
I'm re-checking with the gateway team about what problem they were having with using JAVA_OPTS , which should override the hard-coded value.

[akomakom]

I guess that should work:
https://stackoverflow.com/a/58384752/1735931

[jhouserizer]

Apparently not (specifying JAVA_OPTS), though they are vague as to why, simply saying it fails to start. I guess we need to test for ourselves with existing BM image.

[akomakom]

This produces the expected error:

$ docker run  --rm -it -v /junk/file:/licenses/license.key  -v /junk/file:/configs/tc-config.xml -e JAVA_OPTS="-Xmx500g" -e ACCEPT_EULA=Y   XXXXXXXX/terracotta/bigmemorymax-server:4.3.10.0.68

# There is insufficient memory for the Java Runtime Environment to continue.

and:

-e JAVA_OPTS="-Xmx100m -Xms200m"

Error occurred during initialization of VM
Initial heap size set to a larger value than the maximum heap size

[cljohnso]

Is there any way to see what is actually being passed in? I suspect a quoting issue ...

[jhouserizer]

Is there any way to see what is actually being passed in? I suspect a quoting issue ...

I keep asking them to be specific and they keep being vague. Trying yet again...

[GaryWKeim]

Did you try using an --env-file like:

environment:
    - JAVA_OPTS=-Xmx256m -Xms128m

[mobasherul]

In discussion with Gary, we're having second thoughts about this... I'm re-checking with the gateway team about what problem they were having with using JAVA_OPTS , which should override the hard-coded value.

@jhouserizer In Dockerfile JAVA_OPTS is being used so if u pass it while running container it will cause issue-
ENV JAVA_OPTS "-Dcom.tc.productkey.path=$LICENSE_DIRECTORY/license.key -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap"

so if u pass explicitly JAVA_OPTS while running container it will override the JAVA_OPTS value defined in Dockerfile and I get this error-
specify it as a system property with -Dcom.tc.productkey.path=/path/to/key
2021-11-09 13:55:39,007 ERROR - License key not found
2021-11-09 13:55:39,007 ERROR - License key not found
org.terracotta.license.LicenseException: License key not found
at com.tc.license.LicenseManager.assertLicenseValid(LicenseManager.java:101)
at com.tc.server.EnterpriseServerFactory.verifyLicensePresent(EnterpriseServerFactory.java:30)
at com.tc.server.EnterpriseServerFactory.createServer(EnterpriseServerFactory.java:17)
at com.tc.server.TCServerMain.main(TCServerMain.java:42)
2021-11-09 13:55:39,010 ERROR - Thread:Thread[main,5,main] got an uncaught exception. calling CallbackOnExitDefaultHandlers.
org.terracotta.license.LicenseException: License key not found
at com.tc.license.LicenseManager.assertLicenseValid(LicenseManager.java:101)
at com.tc.server.EnterpriseServerFactory.verifyLicensePresent(EnterpriseServerFactory.java:30)
at com.tc.server.EnterpriseServerFactory.createServer(EnterpriseServerFactory.java:17)
at com.tc.server.TCServerMain.main(TCServerMain.java:42)

[akomakom]

Note that both codelines are doing this:

• 4.x: https://github.com/SoftwareAG/terracotta-cloud/blob/03fce118395d4dc5a764326fb18a2f065d0389e8/docker/images/bigmemorymax-server/Dockerfile#L35
• 10.x: https://github.com/SoftwareAG/terracotta-cloud/blob/cadce04831f60a81a687f27bd31ea583fec2bbfd/docker/images/terracotta-server/Dockerfile#L55-56

Argument for this approach?

[mobasherul]

Note that both codelines are doing this:

• 4.x: https://github.com/SoftwareAG/terracotta-cloud/blob/03fce118395d4dc5a764326fb18a2f065d0389e8/docker/images/bigmemorymax-server/Dockerfile#L35
• 10.x: https://github.com/SoftwareAG/terracotta-cloud/blob/cadce04831f60a81a687f27bd31ea583fec2bbfd/docker/images/terracotta-server/Dockerfile#L55-56

Argument for this approach?

the JAVA_OPTS contain some options I guess that is not supported in java11 i.e - TAB-8036 .

[akomakom]

keeping discussion together:

I'm guessing that this is a non-breaking change. I placed JAVA_MEMORY_OPTS before JAVA_OPTS, which means that:

• users who are currently overriding memory settings via JAVA_OPTS will still be able to (for docker, this means losing default values)
• users can switch to JAVA_MEMORY_OPTS

Questions:

1. Would it be better to rename JAVA_MEMORY_OPTS to JAVA_EXTRA_OPTS?
2. Would it be better to have both JAVA_MEMORY_OPTS and JAVA_EXTRA_OPTS in addition to JAVA_OPTS?
3. Would it be better to rework all of this in some cohesive way?

I ask because I can reasonably expect customers to also want to add arbitrary java tuning flags that aren't memory specific.