Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: FreeBSD
      Platform: All

    • Issuezilla Id:
      11,253

      Description

      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.

        Activity

        Hide
        Hong Zhang added a comment -

        assign to admin team for evaluation

        Show
        Hong Zhang added a comment - assign to admin team for evaluation
        Hide
        Tom Mueller added a comment -

        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).

        Show
        Tom Mueller added a comment - 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).
        Hide
        Tom Mueller added a comment -

        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.

        Show
        Tom Mueller added a comment - 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.

          People

          • Assignee:
            kumara
            Reporter:
            vladperl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: