Solr
  1. Solr
  2. SOLR-6705

SOLR Start script generates warnings on java 8 due ot experimental options

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 4.10.2
    • Fix Version/s: 4.10.3, 5.0
    • Component/s: scripts and tools
    • Labels:
      None
    • Environment:

      Mac Yosemite 10.10
      java -version
      java version "1.8.0_25"
      Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
      Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

      Description

      When using the start script in bin: ./solr start in java 8...

      Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
      Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=256m; support was removed in 8.0
      Java HotSpot(TM) 64-Bit Server VM warning: ignoring option CMSTriggerPermRatio=80; support was removed in 8.0
      Java HotSpot(TM) 64-Bit Server VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release.
      

      ...we should reconsider having these options hardcoded into the start script – either auto-detect if/when they make sense, or remove them

        Issue Links

          Activity

          Hide
          Shawn Heisey added a comment -

          Those messages are there because you're running Java 8. The first three parameters mentioned don't do anything when running Java 8, the last one currently does change behavior, but won't in a future version.

          These parameters DO have meaning to Java 7, which is a supported platform for the currently available Solr releases, and will continue to be supported by the 5.0 release. Increasing PermSize (the first two parameters mentioned) is a perfectly valid thing to do on Java 7. The third and fourth messages refer to garbage collection tuning parameters that are supported by Java 7. They were intentionally included to speed up garbage collection.

          Although it might be possible to include changes that would get rid of these warnings on Java 8, it would make the start script significantly more complicated. That complexity means bugs would be more likely to escape notice and affect users. I would much rather see warnings than bugs.

          I'll leave the issue open right now, in case a committer with more experience has a different take on your concern.

          Show
          Shawn Heisey added a comment - Those messages are there because you're running Java 8. The first three parameters mentioned don't do anything when running Java 8, the last one currently does change behavior, but won't in a future version. These parameters DO have meaning to Java 7, which is a supported platform for the currently available Solr releases, and will continue to be supported by the 5.0 release. Increasing PermSize (the first two parameters mentioned) is a perfectly valid thing to do on Java 7. The third and fourth messages refer to garbage collection tuning parameters that are supported by Java 7. They were intentionally included to speed up garbage collection. Although it might be possible to include changes that would get rid of these warnings on Java 8, it would make the start script significantly more complicated. That complexity means bugs would be more likely to escape notice and affect users. I would much rather see warnings than bugs. I'll leave the issue open right now, in case a committer with more experience has a different take on your concern.
          Hide
          Erick Erickson added a comment -

          In the future, please raise issues like this on the user's list first so we can keep the JIRAs focused on code problems/improvements.

          Show
          Erick Erickson added a comment - In the future, please raise issues like this on the user's list first so we can keep the JIRAs focused on code problems/improvements.
          Hide
          Jan Høydahl added a comment -

          Actually I encouraged Carsten to file an issue for this, as the start script perfectly well can check Java version and optimize the set of options accordingly. It is a very bad OOTB experience for new users to get WARNINGs thrown on a normal legal startup. The argument that they are "supposed to be there" is not a good one, and I'd like us to polish the user experience to be best possible. I'll probably re-open this issue and start looking into it.

          Show
          Jan Høydahl added a comment - Actually I encouraged Carsten to file an issue for this, as the start script perfectly well can check Java version and optimize the set of options accordingly. It is a very bad OOTB experience for new users to get WARNINGs thrown on a normal legal startup. The argument that they are "supposed to be there" is not a good one, and I'd like us to polish the user experience to be best possible. I'll probably re-open this issue and start looking into it.
          Hide
          Hoss Man added a comment -

          the issue certainly seemed like it was phrased as a question that should have started on the user list - but yeah, let's re-open and re-summarize and evaluate

          Show
          Hoss Man added a comment - the issue certainly seemed like it was phrased as a question that should have started on the user list - but yeah, let's re-open and re-summarize and evaluate
          Hide
          Hoss Man added a comment -

          some related comments from Uwe & jan on the dev list:

          uwe...

          Hi,

          I just reviewed the solr.sh.in and solr.cmd.in scripts in solr/bin folder. The following was committed but never discussed:

          # These GC settings have shown to work well for a number of common Solr workloads
          GC_TUNE="-XX:-UseSuperWord \
          -XX:NewRatio=3 \
          -XX:SurvivorRatio=4 \
          -XX:TargetSurvivorRatio=90 \
          -XX:MaxTenuringThreshold=8 \
          -XX:+UseConcMarkSweepGC \
          -XX:+UseParNewGC \
          -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 \
          -XX:+CMSScavengeBeforeRemark \
          -XX:PretenureSizeThreshold=64m \
          -XX:CMSFullGCsBeforeCompaction=1 \
          -XX:+UseCMSInitiatingOccupancyOnly \
          -XX:CMSInitiatingOccupancyFraction=50 \
          -XX:CMSTriggerPermRatio=80 \
          -XX:CMSMaxAbortablePrecleanTime=6000 \
          -XX:+CMSParallelRemarkEnabled \
          -XX:+ParallelRefProcEnabled \
          -XX:+AggressiveOpts"
          

          This is horrible, because of our experience with Hotspot bugs:

          -XX:+AggressiveOpts
          This option is veeeery risky and speed improvements are marginal. PLEASE DON'T DO THIS. If people want the new features they should wait for later Java releases and the new features are tested. See several tasks about the Java 7 disaster! In fact we had reports at Java 6 times when people had enabled this and were affected by the Java 7 GA bugs already in Java 6 and corrupted their indexes!!!

          -XX:-UseSuperWord
          If you have a Haswell CPU, all other improvements in these command line settings are eaten up by this flag! If you have 7u55 at minimum, you should never disable this. Things like BooleanFilter and other bitset operations are up to 2 times faster with Java 7u55 on Haswell CPUs and later!!! This setting only makes sense if you have one of those buggy JDKs (7u40 to 7u51). In all other cases this slows down enormous! In addition, enabling this option may break JDKs before 7u40 (this option was added in 7u40), so breaks:
          > Unrecognized VM option 'UseSuperWord'

          It would be good, if we could fix the startup scripts not not have options, which may also break with JDK 8 or later!

          jan...

          Can we in a smart way build these best practices into the script, by testing JVM version and (un)setting some of these automatically based on version? The solr.in.* config could have a new option GC_TUNE_AUTO="true" and GC_TUNE commented out. Then if auto is enabled, the bin/solr scripts will decide what flags to set. Experts can override.
          Also related is SOLR-6705, some options should be set automatically only for some JVM versions.

          Show
          Hoss Man added a comment - some related comments from Uwe & jan on the dev list: uwe... Hi, I just reviewed the solr.sh.in and solr.cmd.in scripts in solr/bin folder. The following was committed but never discussed: # These GC settings have shown to work well for a number of common Solr workloads GC_TUNE="-XX:-UseSuperWord \ -XX:NewRatio=3 \ -XX:SurvivorRatio=4 \ -XX:TargetSurvivorRatio=90 \ -XX:MaxTenuringThreshold=8 \ -XX:+UseConcMarkSweepGC \ -XX:+UseParNewGC \ -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 \ -XX:+CMSScavengeBeforeRemark \ -XX:PretenureSizeThreshold=64m \ -XX:CMSFullGCsBeforeCompaction=1 \ -XX:+UseCMSInitiatingOccupancyOnly \ -XX:CMSInitiatingOccupancyFraction=50 \ -XX:CMSTriggerPermRatio=80 \ -XX:CMSMaxAbortablePrecleanTime=6000 \ -XX:+CMSParallelRemarkEnabled \ -XX:+ParallelRefProcEnabled \ -XX:+AggressiveOpts" This is horrible, because of our experience with Hotspot bugs: -XX:+AggressiveOpts This option is veeeery risky and speed improvements are marginal. PLEASE DON'T DO THIS. If people want the new features they should wait for later Java releases and the new features are tested. See several tasks about the Java 7 disaster! In fact we had reports at Java 6 times when people had enabled this and were affected by the Java 7 GA bugs already in Java 6 and corrupted their indexes!!! -XX:-UseSuperWord If you have a Haswell CPU, all other improvements in these command line settings are eaten up by this flag! If you have 7u55 at minimum, you should never disable this. Things like BooleanFilter and other bitset operations are up to 2 times faster with Java 7u55 on Haswell CPUs and later!!! This setting only makes sense if you have one of those buggy JDKs (7u40 to 7u51). In all other cases this slows down enormous! In addition, enabling this option may break JDKs before 7u40 (this option was added in 7u40), so breaks: > Unrecognized VM option 'UseSuperWord' It would be good, if we could fix the startup scripts not not have options, which may also break with JDK 8 or later! jan... Can we in a smart way build these best practices into the script, by testing JVM version and (un)setting some of these automatically based on version? The solr.in.* config could have a new option GC_TUNE_AUTO="true" and GC_TUNE commented out. Then if auto is enabled, the bin/solr scripts will decide what flags to set. Experts can override. Also related is SOLR-6705 , some options should be set automatically only for some JVM versions.
          Hide
          Erick Erickson added a comment -

          fair enough, sorry for jumping the gun here. No harm, no foul.

          Show
          Erick Erickson added a comment - fair enough, sorry for jumping the gun here. No harm, no foul.
          Hide
          Jan Høydahl added a comment -

          Timothy Potter, see also the patch @ SOLR-6693 where I added detection of Solr version and 32/64 bit as part of that issue. Could be used for further decision making. One approach I thought of is to split GC into three variables in solr.in.sh: GC_TUNE, GC_TUNE_JAVA7 and GC_TUNE_JAVA8, and move version-specific options over to the respective vars. Just an idea.

          Show
          Jan Høydahl added a comment - Timothy Potter , see also the patch @ SOLR-6693 where I added detection of Solr version and 32/64 bit as part of that issue. Could be used for further decision making. One approach I thought of is to split GC into three variables in solr.in.sh : GC_TUNE , GC_TUNE_JAVA7 and GC_TUNE_JAVA8 , and move version-specific options over to the respective vars. Just an idea.
          Hide
          Timothy Potter added a comment -

          Thanks Jan Høydahl for helping out with the 32-bit windows script issues!

          For this, here's what I'm thinking of adding to the *nix script

          JAVA_VERSION=`echo "$(java -version 2>&1)" | grep "java version" | awk '{ print substr($3, 2, length($3)-2); }'`
          if [ "${JAVA_VERSION:0:3}" == "1.7" ]; then
            # Specific Java version hacking
            GC_TUNE="$GC_TUNE -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSTriggerPermRatio=80"
            JAVA_MINOR_VERSION=${JAVA_VERSION:(-2)}
            if [[ $JAVA_MINOR_VERSION -ge 40 && $JAVA_MINOR_VERSION -le 51 ]]; then
              GC_TUNE="$GC_TUNE -XX:-UseSuperWord"
              echo -e "\nWARNING: Java version $JAVA_VERSION has known bugs with Lucene and requires the -XX:-UseSuperWord flag. Please consider upgrading your JVM.\n"
            fi
          fi
          

          Obviously the problematic flags will be removed from the default GC_TUNE settings in solr.in.sh and then just enabled for specific versions.

          Show
          Timothy Potter added a comment - Thanks Jan Høydahl for helping out with the 32-bit windows script issues! For this, here's what I'm thinking of adding to the *nix script JAVA_VERSION=`echo "$(java -version 2>&1)" | grep "java version" | awk '{ print substr($3, 2, length($3)-2); }'` if [ "${JAVA_VERSION:0:3}" == "1.7" ]; then # Specific Java version hacking GC_TUNE= "$GC_TUNE -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSTriggerPermRatio=80" JAVA_MINOR_VERSION=${JAVA_VERSION:(-2)} if [[ $JAVA_MINOR_VERSION -ge 40 && $JAVA_MINOR_VERSION -le 51 ]]; then GC_TUNE= "$GC_TUNE -XX:-UseSuperWord" echo -e "\nWARNING: Java version $JAVA_VERSION has known bugs with Lucene and requires the -XX:-UseSuperWord flag. Please consider upgrading your JVM.\n" fi fi Obviously the problematic flags will be removed from the default GC_TUNE settings in solr.in.sh and then just enabled for specific versions.
          Hide
          ASF subversion and git services added a comment -

          Commit 1638022 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1638022 ]

          SOLR-6705: better handling of JVM version specific options

          Show
          ASF subversion and git services added a comment - Commit 1638022 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1638022 ] SOLR-6705 : better handling of JVM version specific options
          Hide
          ASF subversion and git services added a comment -

          Commit 1638023 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1638023 ]

          SOLR-6705: better handling of JVM version specific options

          Show
          ASF subversion and git services added a comment - Commit 1638023 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1638023 ] SOLR-6705 : better handling of JVM version specific options
          Hide
          ASF subversion and git services added a comment -

          Commit 1638024 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1638024 ]

          SOLR-6705: better handling of JVM version specific options

          Show
          ASF subversion and git services added a comment - Commit 1638024 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1638024 ] SOLR-6705 : better handling of JVM version specific options
          Hide
          ASF subversion and git services added a comment -

          Commit 1638429 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1638429 ]

          SOLR-6705: Add specific JVM version checking to Windows start scripts

          Show
          ASF subversion and git services added a comment - Commit 1638429 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1638429 ] SOLR-6705 : Add specific JVM version checking to Windows start scripts
          Hide
          ASF subversion and git services added a comment -

          Commit 1638477 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1638477 ]

          SOLR-6705: Add specific JVM version checking to Windows start scripts

          Show
          ASF subversion and git services added a comment - Commit 1638477 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1638477 ] SOLR-6705 : Add specific JVM version checking to Windows start scripts
          Hide
          ASF subversion and git services added a comment -

          Commit 1638484 from Timothy Potter in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1638484 ]

          SOLR-6705: Add specific JVM version checking to Windows start scripts

          Show
          ASF subversion and git services added a comment - Commit 1638484 from Timothy Potter in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1638484 ] SOLR-6705 : Add specific JVM version checking to Windows start scripts
          Hide
          ASF subversion and git services added a comment -

          Commit 1638485 from Timothy Potter in branch 'dev/trunk'
          [ https://svn.apache.org/r1638485 ]

          SOLR-6705: mention fix in changes

          Show
          ASF subversion and git services added a comment - Commit 1638485 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1638485 ] SOLR-6705 : mention fix in changes
          Hide
          Anshum Gupta added a comment -

          Bulk close after 5.0 release.

          Show
          Anshum Gupta added a comment - Bulk close after 5.0 release.

            People

            • Assignee:
              Timothy Potter
              Reporter:
              Carsten Grønbjerg Lützen
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development