[GLASSFISH-11253] possibility to update jvm-options Created: 04/Dec/09  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: vladperl Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: FreeBSD
Platform: All

Issuezilla Id: 11,253


In current situation to change value of JVM option we have to delete the option
first and then create it again.
I suggest to introduce new parameter "--replace" to command "create-jvm-options"
that will force to update value of the same parameter in case it already exists.
Without this parameter the same option appears twice if it was already exists
before the command "create-jvm-options" started.

Comment by Hong Zhang [ 04/Dec/09 ]

assign to admin team for evaluation

Comment by Tom Mueller [ 06/Jan/11 ]

There are several flavors of JVM options that can be set:

1. "plain" options, such as -client, -server, -esa, etc. Some of these are related to one another. For example, if setting -d32, then if there is a -d64 option, it should be replaced.

2. value options without an equals, such as -Xmx512m. If setting -Xmx256m, then -Xmx512m should be replaced.

3. value options with an equals, such as -Da=b or -XX:MaxPermSize=192m. If setting -Da=c, then -Da=b should be replaced.

Since options in flavor 3 are not cumulative, the create-jvm-options command could just automatically provide the replacement behavior without a --replace option. Maybe a warning could be printed to say that replacement is happening. Is there any situation where adding multiple options with the same value before the "=" is desired?

For options in flavors 1 and 2, the create-jvm-options command would need to have knowledge about the options and how they are related, which increases the coupling between the create-jvm-options command and a particular JVM.

For -Xmx and -Xms, the create-jvm-options already has this coupling, but rather than replacing and existing value for one of those options, it adds the additional option and warns that there was already an option for that value (which doesn't seem to be the right behavior).

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

Generated at Wed Dec 07 10:50:11 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.