Plugin script fails when memory parameters are defined in environment file

[jaymode]

The plugin script fails to initialize when the the environment file (for DEB installations, /etc/default/elasticsearch) is sourced and contains memory parameters in ES_JAVA_OPTS such as a larger new size.

Example output:

$ bin/plugin -r pluginname
Error occurred during initialization of VM
Too small initial heap for new size specified

This is caused by the hardcoded Xmx and Xms parameters in the plugin script. Removing the hardcoded values allows the script to execute successfully.

We may be able to just use the default JVM values here instead of hardcoding these values.

[spinscale]

steps to reproduce:

• You need java 1.7, does not happen with java 1.8
• set ES_JAVA_OPTS="-XX:NewSize=256m" in /etc/default/elasticsearch

Then call the plugin manager like

# /usr/share/elasticsearch/bin/plugin
Error occurred during initialization of VM
Too small initial heap for new size specified

I am not sure if it is a good idea to remove those values, because this means, that you can potentially run the plugin manager with the same heap configured than your elasticsearch process, given you used -Xms and -Xmx instead of ES_HEAP_SIZE, which is never used in the plugin manager

As java 7 is EOL and it works with Java8, I am currently leaning towards closing this, as soon as I figured out, what actually happens in Java8 - as in what values are really getting used and which get ignored.

Update: No need to have a package installed, you can simply use JAVA_OPTS on osx as well and call bin/plugin

[spinscale]

So, using a small java class, that basically prints out ManagementFactory.getMemoryMXBean().getHeapMemoryUsage() shows, that java8 is doing the right thing and respects Xmx and Xms

java8:

# java -XX:NewSize=256m -Xmx64m -Xms16m Foo
init = 16777216(16384K) used = 1311456(1280K) committed = 15204352(14848K) max = 45613056(44544K)
# java -Xmx64m -Xms16m Foo
init = 16777216(16384K) used = 872696(852K) committed = 16252928(15872K) max = 59768832(58368K)

java7 (obviously)

# java -XX:NewSize=256m -Xmx64m -Xms16m Foo
Error occurred during initialization of VM
Too small initial heap for new size specified
# java -Xmx64m -Xms16m Foo
init = 16777216(16384K) used = 480376(469K) committed = 16777216(16384K) max = 59768832(58368K)

@jaymode objections against leaving as it is to prevent accidentally crazy high heaps for the plugin manager if people configure -Xmx in the JAVA_OPTS or ES_JAVA_OPTS for Elasticsearch itself?

[jaymode]

I'm ok with leaving memory values specified.

I think the question is can we do anything to make an error less likely if memory values are configured in that option? I can't think of a good option since sourcing the config files has value. Maybe we don't use ES_JAVA_OPTS and introduce a CLI_JAVA_OPTS or something?

[spinscale]

this also raises an interesting point, if we want to merge the plugin manager into the BootstrapCliParser as this means, both have to run with the same memory settings, which might be bad...

[spinscale]

so we would need ES_JAVA_OPTS, PLUGIN_JAVA_OPTS and COMMON_JAVA_OPTS or are two options sufficient? Just mapping it out... given the single hit we had with this, I would postpone it for now

[rjernst]

why doe the plugin manager need java opts at all?

[jaymode]

We've used the ES_JAVA_OPTS as a way to specify a custom conf directory/file location. That was before we started reading those files.

I think removing both JAVA_OPTS and ES_JAVA_OPTS is ok since we:

1. read the environment configuration files for RPM/DEB now
2. have the ability to specify the options with -- syntax

[rjernst]

Regardless of whether we remove those env settings, I don't see why plugin manager needs them. This is a tiny program that just installs/removes/lists plugins. It should not require setting eg heap size or crazy other java options.

[jaymode]

Regardless of whether we remove those env settings, I don't see why plugin manager needs them.

+1

[spinscale]

so, removing JAVA_OPTS and ES_JAVA_OPTS settings still pass all integration tests... and works under CentOS, going to create a PR after testing the debian package