Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
If you start a server/locator by specifying both max-heap and -XX:CMSInitiatingOccupancyFraction, logs show that a default CMSInitiatingOccupancyFraction` is also added in addition to the user specified value.
As an example, the command start server --name=server1 --max-heap=1g --J=-XX:CMSInitiatingOccupancyFraction=50 --server-port=0 produces the following output:
Command Line Parameters: -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true -XX:CMSInitiatingOccupancyFraction=50 -XX:OnOutOfMemoryError=kill -KILL %p -Xmx1g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
There are 2 entries for XX:CMSInitiatingOccupancyFraction.
The problem resides within the addMaxHeap method of the StartMemberUtils class:
static void addMaxHeap(final List<String> commandLine, final String maxHeap) { if (StringUtils.isNotBlank(maxHeap)) { commandLine.add("-Xmx" + maxHeap); commandLine.add("-XX:+UseConcMarkSweepGC"); commandLine.add("-XX:CMSInitiatingOccupancyFraction=" + CMS_INITIAL_OCCUPANCY_FRACTION); } }
The method is called by both the StartLocatorCommand and StartServerCommand after the jvmArgs have been already added to the parsed commandLine. The solution would be to simply check the collection before adding the -XX:CMSInitiatingOccupancyFraction option.
Attachments
Issue Links
- links to