Solr
  1. Solr
  2. SOLR-6693

Start script for windows fails with 32bit JRE

    Details

      Description

      Reproduce:

      1. Install JRE8 from www.java.com (typically C:\Program Files (x86)\Java\jre1.8.0_25)
      2. Run the command bin\solr start -V

      The result is:
      \Java\jre1.8.0_25\bin\java was unexpected at this time.

      Reason
      This comes from bad quoting of the %SOLR% variable. I think it's because of the parenthesis that it freaks out. I think the same would apply for a 32-bit JDK because of the (x86) in the path, but I have not tested.

      Tip: You can remove the line @ECHO OFF at the top to see exactly which is the offending line

      Solution
      Quoting the lines where %JAVA% is printed, e.g. instead of

        @echo Using Java: %JAVA%
      

      then use

        @echo "Using Java: %JAVA%"
      

      This is needed several places.

      1. solr.cmd
        31 kB
        Christopher Hewitt
      2. solr.cmd.patch
        9 kB
        Christopher Hewitt
      3. SOLR-6693.patch
        12 kB
        Timothy Potter
      4. SOLR-6693.patch
        9 kB
        Timothy Potter
      5. SOLR-6693.patch
        5 kB
        Jan Høydahl
      6. SOLR-6693-lucene_solr_4_10.patch
        12 kB
        Steve Rowe

        Issue Links

          Activity

          Hide
          Jan Høydahl added a comment -

          After fixing the echo problems, the next hurdle occurs:
          Java 1.7 or later is required to run Solr.

          Even if I have Java8 (32bit). After some debugging, I found that the syntax -version:x.y does not work on 32-bit java for Windows, it prints the error even if you have the right version.

          So the question then is, should the script enforce 64bit Java and print a more useful message if not found? Or is there a way to fix the version testing under 32-bit Java on Windows? It would perhaps be good to print a warning for 32-bit Java since you should use 64bit if possible

          Show
          Jan Høydahl added a comment - After fixing the echo problems, the next hurdle occurs: Java 1.7 or later is required to run Solr. Even if I have Java8 (32bit). After some debugging, I found that the syntax -version:x.y does not work on 32-bit java for Windows, it prints the error even if you have the right version. So the question then is, should the script enforce 64bit Java and print a more useful message if not found? Or is there a way to fix the version testing under 32-bit Java on Windows? It would perhaps be good to print a warning for 32-bit Java since you should use 64bit if possible
          Hide
          Daniel Collins added a comment -

          Jan, quoting issue aside, the -version syntax does seem to work in Windows even for 32-bit JVMs?

          C:\Users\dcollins53>"C:\Program Files (x86)\Java\jre1.8.0_20\bin\java" -version:1.8 -version
          java version "1.8.0_20"
          Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
          Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode)
          
          C:\Users\dcollins53>"C:\Program Files\Java\jre1.8.0_20\bin\java" -version:1.8 -version
          java version "1.8.0_20"
          Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
          Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
          

          I confess I don't have any Java 7 JVMs any more, but Java 8 32-bit does seem to be printing the right output. Whether the solr.cmd script is handling it correctly, I haven't checked, but it should be possible to get that to work.

          Show
          Daniel Collins added a comment - Jan, quoting issue aside, the -version syntax does seem to work in Windows even for 32-bit JVMs? C:\Users\dcollins53>"C:\Program Files (x86)\Java\jre1.8.0_20\bin\java" -version:1.8 -version java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode) C:\Users\dcollins53>"C:\Program Files\Java\jre1.8.0_20\bin\java" -version:1.8 -version java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) I confess I don't have any Java 7 JVMs any more, but Java 8 32-bit does seem to be printing the right output. Whether the solr.cmd script is handling it correctly, I haven't checked, but it should be possible to get that to work.
          Hide
          Jan Høydahl added a comment -

          On my windows 8.1 (running in VmWare on my Mac) I get

          C:\>"C:\Program Files (x86)\Java\jdk1.8.0_25\bin\java" -version:1.8 -version
          Error: Unable to locate JRE meeting specification "1.8"
          C:\>"C:\Program Files (x86)\Java\jdk1.8.0_25\jre\bin\java.exe" -version:1.8 -version
          Error: Unable to locate JRE meeting specification "1.8"
          C:\>echo %JAVA_HOME%
          "C:\Program Files (x86)\Java\jdk1.8.0_25\jre"
          
          Show
          Jan Høydahl added a comment - On my windows 8.1 (running in VmWare on my Mac) I get C:\>"C:\Program Files (x86)\Java\jdk1.8.0_25\bin\java" -version:1.8 -version Error: Unable to locate JRE meeting specification "1.8" C:\>"C:\Program Files (x86)\Java\jdk1.8.0_25\jre\bin\java.exe" -version:1.8 -version Error: Unable to locate JRE meeting specification "1.8" C:\>echo %JAVA_HOME% "C:\Program Files (x86)\Java\jdk1.8.0_25\jre"
          Hide
          Daniel Collins added a comment -

          Strange, I'm on Windows 7, and with a slightly older Java8 VM, but I can't see why any of those things would affect the results.
          I confess my usual resolution to any oddities with Java VMs on Windows is to uninstall and re-install the JVM (often twice!) which usually seems to "deal" with it... Its not pretty or scientific but it seems to help.

          Show
          Daniel Collins added a comment - Strange, I'm on Windows 7, and with a slightly older Java8 VM, but I can't see why any of those things would affect the results. I confess my usual resolution to any oddities with Java VMs on Windows is to uninstall and re-install the JVM (often twice!) which usually seems to "deal" with it... Its not pretty or scientific but it seems to help.
          Hide
          Jan Høydahl added a comment -

          On the same Windows, this works with 64bit Java

          C:\>"C:\Program Files\Java\jdk1.8.0\bin\java" -version:1.8 -version
          java version "1.8.0_20"
          Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
          Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
          
          Show
          Jan Høydahl added a comment - On the same Windows, this works with 64bit Java C:\>"C:\Program Files\Java\jdk1.8.0\bin\java" -version:1.8 -version java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
          Hide
          Jan Høydahl added a comment -

          After uninstalling all Javas and reinstalling only JDK 32-bit, the version command works. Must be some Win registry mess? Btw. Do any of you know what the C:\Windows\System32\java.exe file is? Is it placed there by Oracle installer?

          Show
          Jan Høydahl added a comment - After uninstalling all Javas and reinstalling only JDK 32-bit, the version command works. Must be some Win registry mess? Btw. Do any of you know what the C:\Windows\System32\java.exe file is? Is it placed there by Oracle installer?
          Hide
          Mark Miller added a comment -

          On a bit of reading, I believe it's part of the windows jdk/jre install and that it acts like /bin/java might - it will be found on the path and it looks in the registry to launch the configured java executable.

          Show
          Mark Miller added a comment - On a bit of reading, I believe it's part of the windows jdk/jre install and that it acts like /bin/java might - it will be found on the path and it looks in the registry to launch the configured java executable.
          Show
          Mark Miller added a comment - http://mindprod.com/jgloss/javaexe.html#MULTIPLES
          Hide
          Daniel Collins added a comment -

          Yeah, I was half-joking and half-serious when I suggested JVM re-install.
          Windows JVM installs always seem somewhat prone to needing a re-install from time to time, The C:\Windows\System32\java.exe always seems to favour the "last" JVM you installed as well, so if you have (for example) a Java 7 and Java 8 JVM installed, and then you update your Java 7 JVM, that becomes the new "default". You have to re-update Java 8 to update that magic version of java.exe.

          It always makes me glad to get back to Linux every time I have to use Windows, at least there applications get installed into directories, if they are on your path (or I explicitly run them), they get used, if they aren't, they don't. It makes so much more sense that way

          Show
          Daniel Collins added a comment - Yeah, I was half-joking and half-serious when I suggested JVM re-install. Windows JVM installs always seem somewhat prone to needing a re-install from time to time, The C:\Windows\System32\java.exe always seems to favour the "last" JVM you installed as well, so if you have (for example) a Java 7 and Java 8 JVM installed, and then you update your Java 7 JVM, that becomes the new "default". You have to re-update Java 8 to update that magic version of java.exe . It always makes me glad to get back to Linux every time I have to use Windows, at least there applications get installed into directories, if they are on your path (or I explicitly run them), they get used, if they aren't, they don't. It makes so much more sense that way
          Hide
          Jan Høydahl added a comment -

          First patch

          • Fixes echo print of variable containing unsafe chars like )
          • Detects Java version, JRE/JDK and 32/64bit
          • Prints warning if 32 bit or if no support for -server arg

          All in all, this patch lets Windows users test Solr even if they only have a 32bit JRE installed, but the warnings will urge them to choose another JVM for production.

          Show
          Jan Høydahl added a comment - First patch Fixes echo print of variable containing unsafe chars like ) Detects Java version, JRE/JDK and 32/64bit Prints warning if 32 bit or if no support for -server arg All in all, this patch lets Windows users test Solr even if they only have a 32bit JRE installed, but the warnings will urge them to choose another JVM for production.
          Hide
          Jan Høydahl added a comment -

          Experiencing a weird behavior on a Windows where I have several JVMs installed. When calling e.g. "C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.8 -version it somehow finds my 1.8 install and uses that. Shell output:

          C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version
          java version "1.6.0_45"
          Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
          Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
          
          C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.7 -version
          java version "1.7.0_71"
          Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
          Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
          
          C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.7+ -version
          java version "1.8.0_25"
          Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
          Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
          
          C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.8 -version
          java version "1.8.0_25"
          Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
          Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
          

          So the -version:x.y flag cannot be used to detect the version of that particular executable. Cannot reproduce this behavior on my Mac, probably because there is no central registry listing all installed Javas. So we have a few choices for Windows:

          A) Do not require JAVA_HOME to be set, but instead try simply calling java -version:1.7+ when starting Solr
          B) Use JAVA_HOME and parse Java version from the -version output

          Thoughts?

          Show
          Jan Høydahl added a comment - Experiencing a weird behavior on a Windows where I have several JVMs installed. When calling e.g. "C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.8 -version it somehow finds my 1.8 install and uses that. Shell output: C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode) C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.7 -version java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.7+ -version java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) C:\>"C:\Program Files\Java\jdk1.6.0_45\bin\java.exe" -version:1.8 -version java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) So the -version:x.y flag cannot be used to detect the version of that particular executable. Cannot reproduce this behavior on my Mac, probably because there is no central registry listing all installed Javas. So we have a few choices for Windows: A) Do not require JAVA_HOME to be set, but instead try simply calling java -version:1.7+ when starting Solr B) Use JAVA_HOME and parse Java version from the -version output Thoughts?
          Hide
          jmlucjav added a comment -

          I never install the JRE in my dev hosts, what I do is: install the jdk, copy the jdk dir to another place A, set JAVA_HOME pointing to A, then uninstall the jdk, this way I have several 'clean' jdks I can use by changing JAVA_HOME and PATH, nothing in the registry (well, only browser plugin related stuff but this is another matter).

          With this setup of mine, the -version:x.y syntax does not work, seems it specifically looks for a JRE:

          java -version
          java version "1.7.0_60"
          Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
          Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
          
          java -version:1.7+
          Error: Unable to locate JRE meeting specification "1.7+"
          

          so if possible I would avoid using

          -version:x.y 
          Show
          jmlucjav added a comment - I never install the JRE in my dev hosts, what I do is: install the jdk, copy the jdk dir to another place A, set JAVA_HOME pointing to A, then uninstall the jdk, this way I have several 'clean' jdks I can use by changing JAVA_HOME and PATH, nothing in the registry (well, only browser plugin related stuff but this is another matter). With this setup of mine, the -version:x.y syntax does not work, seems it specifically looks for a JRE: java -version java version "1.7.0_60" Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode) java -version:1.7+ Error: Unable to locate JRE meeting specification "1.7+" so if possible I would avoid using -version:x.y
          Hide
          Jan Høydahl added a comment -

          Proposed logic: If JAVA_HOME is set, check its version by string parsing and fail if wrong ver. If no JAVA_HOME then simply attempt java -version:1.7+ and if ok, start Solr with that option.

          Show
          Jan Høydahl added a comment - Proposed logic: If JAVA_HOME is set, check its version by string parsing and fail if wrong ver. If no JAVA_HOME then simply attempt java -version:1.7+ and if ok, start Solr with that option.
          Hide
          jmlucjav added a comment -

          sounds good to me

          Show
          jmlucjav added a comment - sounds good to me
          Hide
          Timothy Potter added a comment -

          I've added Java version parsing to the script to determine if specific JVM flags should be enabled, but I think we can re-use this approach to solve this issue (with a little refactoring). I can do the work, but I don't have a 32-bit windows environment to test with.

          @REM Add Java version specific flags if needed
          set JAVAVER=
          set JAVA_MAJOR=
          set JAVA_BUILD=0
          
          "%JAVA%" -version 2>&1 | findstr /i "version" > javavers
          set /p JAVAVEROUT=<javavers
          del javavers
          for /f "tokens=3" %%g in ("!JAVAVEROUT!") do (
            set JAVAVER=%%g
            set JAVAVER=!JAVAVER:"=!
            for /f "delims=_ tokens=1-3" %%v in ("!JAVAVER!") do (
              set JAVA_MAJOR=!JAVAVER:~0,3!
              set /a JAVA_BUILD=%%w
            )
          )
          IF "!JAVA_MAJOR!"=="1.7" (
            set "GC_TUNE=%GC_TUNE% -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSTriggerPermRatio=80"
            IF !JAVA_BUILD! GEQ 40 (
              IF !JAVA_BUILD! LEQ 51 (
                set "GC_TUNE=!GC_TUNE! -XX:-UseSuperWord"
                @echo WARNING: Java version !JAVAVER! has known bugs with Lucene and requires the -XX:-UseSuperWord flag. Please consider upgrading your JVM.
              )
            )
          )
          
          Show
          Timothy Potter added a comment - I've added Java version parsing to the script to determine if specific JVM flags should be enabled, but I think we can re-use this approach to solve this issue (with a little refactoring). I can do the work, but I don't have a 32-bit windows environment to test with. @REM Add Java version specific flags if needed set JAVAVER= set JAVA_MAJOR= set JAVA_BUILD=0 "%JAVA%" -version 2>&1 | findstr /i "version" > javavers set /p JAVAVEROUT=<javavers del javavers for /f "tokens=3" %%g in ( "!JAVAVEROUT!" ) do ( set JAVAVER=%%g set JAVAVER=!JAVAVER:"=! for /f "delims=_ tokens=1-3" %%v in ( "!JAVAVER!" ) do ( set JAVA_MAJOR=!JAVAVER:~0,3! set /a JAVA_BUILD=%%w ) ) IF "!JAVA_MAJOR!" == "1.7" ( set "GC_TUNE=%GC_TUNE% -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSTriggerPermRatio=80" IF !JAVA_BUILD! GEQ 40 ( IF !JAVA_BUILD! LEQ 51 ( set "GC_TUNE=!GC_TUNE! -XX:-UseSuperWord" @echo WARNING: Java version !JAVAVER! has known bugs with Lucene and requires the -XX:-UseSuperWord flag. Please consider upgrading your JVM. ) ) )
          Hide
          Christopher Hewitt added a comment - - edited

          Occurs in Windows 7, 32bit jre (or jdk), e.g. C:\Program Files (x86)\Java\jdk1.7.0_60;

          It actually comes from proper escaping/encapsulation of parentheses within variables, and the nested IF's ():

          IF "%verbose%"=="1" (
            @echo Using Solr root directory: %SOLR_TIP%
            @echo Using Java: %JAVA%
          
            "%JAVA%" -version
          )
          

          A parenthesis in either %SOLR_TIP% or %JAVA% would break this code. However:

          IF "%verbose%"=="1" (
            @echo Using Solr root directory: "%SOLR_TIP%"
            @echo Using Java: "%JAVA%"
          
            "%JAVA%" -version
          )
          

          Does work..

          Also in this:

          "%JAVA_HOME%"\bin\java -version does not work in the version check, (returns help --?) however:
          "%JAVA_HOME%\bin\java" -version does.

          Show
          Christopher Hewitt added a comment - - edited Occurs in Windows 7, 32bit jre (or jdk), e.g. C:\Program Files (x86)\Java\jdk1.7.0_60 ; It actually comes from proper escaping/encapsulation of parentheses within variables, and the nested IF's (): IF "%verbose%" == "1" ( @echo Using Solr root directory: %SOLR_TIP% @echo Using Java: %JAVA% "%JAVA%" -version ) A parenthesis in either %SOLR_TIP% or %JAVA% would break this code. However: IF "%verbose%" == "1" ( @echo Using Solr root directory: "%SOLR_TIP%" @echo Using Java: "%JAVA%" "%JAVA%" -version ) Does work.. Also in this: "%JAVA_HOME%"\bin\java -version does not work in the version check, (returns help --?) however: "%JAVA_HOME%\bin\java" -version does.
          Hide
          Christopher Hewitt added a comment - - edited

          Attached new solr.cmd:

          This fixes the problems as per my previous comment:

          • JRE in parenthesis directory
          • "%JAVA_HOME%"\bin\java version info
          • Solr in parenthesis directory

          No requirement for JRE/JDK in 64bit environment: Program Files (x86) is supported

          Show
          Christopher Hewitt added a comment - - edited Attached new solr.cmd: This fixes the problems as per my previous comment: JRE in parenthesis directory "%JAVA_HOME%"\bin\java version info Solr in parenthesis directory No requirement for JRE/JDK in 64bit environment: Program Files (x86) is supported
          Hide
          Jan Høydahl added a comment -

          Thanks for the patch. Which version of Solr is it for?

          Show
          Jan Høydahl added a comment - Thanks for the patch. Which version of Solr is it for?
          Hide
          Christopher Hewitt added a comment -

          Ah, sorry... Forgot to mention.. This is for the current release of Solr... 4.10.3

          Show
          Christopher Hewitt added a comment - Ah, sorry... Forgot to mention.. This is for the current release of Solr... 4.10.3
          Hide
          Timothy Potter added a comment -

          We should get this into 5.0 ... I can migrate the patch for the solr.cmd in 5.0 unless you're going to pick it up Jan Høydahl?

          Show
          Timothy Potter added a comment - We should get this into 5.0 ... I can migrate the patch for the solr.cmd in 5.0 unless you're going to pick it up Jan Høydahl ?
          Hide
          Jan Høydahl added a comment -

          Timothy Potter, feel free!

          Show
          Jan Høydahl added a comment - Timothy Potter , feel free!
          Hide
          Timothy Potter added a comment -

          Here's a patch for trunk that incorporates Jan Høydahl's patch from Nov-06 (sorry I overlooked that previously and there was some very good stuff in it) and Christopher Hewitt's patch from earlier this week. It also fixes SOLR-7047.

          We would like to get this into the 5.0 release, but I'm not comfortable doing that without someone else trying this patch out in their environment. I tested with a JRE installed in c:\Program Files (x86)\Java\jre7 and solr installed in: c:\solr (5.0).

          Please review / try this out ASAP and let me know if there are any other issues.

          Show
          Timothy Potter added a comment - Here's a patch for trunk that incorporates Jan Høydahl 's patch from Nov-06 (sorry I overlooked that previously and there was some very good stuff in it) and Christopher Hewitt 's patch from earlier this week. It also fixes SOLR-7047 . We would like to get this into the 5.0 release, but I'm not comfortable doing that without someone else trying this patch out in their environment. I tested with a JRE installed in c:\Program Files (x86)\Java\jre7 and solr installed in: c:\solr (5.0) . Please review / try this out ASAP and let me know if there are any other issues.
          Hide
          Jan Høydahl added a comment -

          Thanks for bringing this forward, Timothy Potter

          Have not tested the patch, but please do not use the resolve_java_version function from my earlier patch. As noted in this comment it will not test whether your specific Java is a certain version, but use the registry to see if it finds ANY Java in the system satisfying the requirements.

          So I propose you continue using the java -version string parsing you started on, perhaps extending it a bit.

          Show
          Jan Høydahl added a comment - Thanks for bringing this forward, Timothy Potter Have not tested the patch, but please do not use the resolve_java_version function from my earlier patch. As noted in this comment it will not test whether your specific Java is a certain version, but use the registry to see if it finds ANY Java in the system satisfying the requirements. So I propose you continue using the java -version string parsing you started on, perhaps extending it a bit.
          Hide
          Timothy Potter added a comment -

          Thanks for the heads-up on the issues with resolve_java_version Jan Høydahl ... From what I can tell, the best approach is to use my java -version string parsing as you suggested, but still use some of your -d64 and -server checking. Cooking up a new patch now ...

          Show
          Timothy Potter added a comment - Thanks for the heads-up on the issues with resolve_java_version Jan Høydahl ... From what I can tell, the best approach is to use my java -version string parsing as you suggested, but still use some of your -d64 and -server checking. Cooking up a new patch now ...
          Hide
          Timothy Potter added a comment -

          Updated patch that does the following:

          • Uses basic parsing of the output from java -version to determine the version; this addresses the issue Jan found about Windows using whatever from the registry
          • Verifies java.exe exists in %JAVA_HOME%\bin
          • Warns user if -server or -d64 are not supported (great addition from Jan)
          • Works with spaces and parens in Java and Solr paths

          When I backport this to branch5x, I'll have to update the script to verify Java 7 instead of 8 ... Please give this a good review / test as we need to cut 5.0 ASAP.

          Show
          Timothy Potter added a comment - Updated patch that does the following: Uses basic parsing of the output from java -version to determine the version; this addresses the issue Jan found about Windows using whatever from the registry Verifies java.exe exists in %JAVA_HOME%\bin Warns user if -server or -d64 are not supported (great addition from Jan) Works with spaces and parens in Java and Solr paths When I backport this to branch5x, I'll have to update the script to verify Java 7 instead of 8 ... Please give this a good review / test as we need to cut 5.0 ASAP.
          Hide
          ASF subversion and git services added a comment -

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

          SOLR-6693: bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME

          Show
          ASF subversion and git services added a comment - Commit 1658423 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1658423 ] SOLR-6693 : bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME
          Hide
          ASF subversion and git services added a comment -

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

          SOLR-6693: bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME

          Show
          ASF subversion and git services added a comment - Commit 1658426 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1658426 ] SOLR-6693 : bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME
          Hide
          ASF subversion and git services added a comment -

          Commit 1658428 from Timothy Potter in branch 'dev/branches/lucene_solr_5_0'
          [ https://svn.apache.org/r1658428 ]

          SOLR-6693: bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME

          Show
          ASF subversion and git services added a comment - Commit 1658428 from Timothy Potter in branch 'dev/branches/lucene_solr_5_0' [ https://svn.apache.org/r1658428 ] SOLR-6693 : bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME
          Hide
          Anshum Gupta added a comment -

          Bulk close after 5.0 release.

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

          Reopening to backport to 4.10.4

          Show
          Steve Rowe added a comment - Reopening to backport to 4.10.4
          Hide
          Steve Rowe added a comment -

          Backported patch.

          I tested on Win 7 with 32-bit Oracle JDK 1.7.0_72. Without this patch, bin\solr start fails for me on the lucene_solr_4_10 branch in the same way as in the issue description.

          With this patch, under both 32-bit 1.7.0_72 and 64-bit 1.7.0_25, the following worked for me:

          • bin\solr start / bin\solr stop -all
          • bin\solr start / bin\solr stop -p 8983
          • bin\solr start / bin\solr start (appropriate error printed)
          • bin\solr start / bin\solr -i

          Committing shortly.

          Show
          Steve Rowe added a comment - Backported patch. I tested on Win 7 with 32-bit Oracle JDK 1.7.0_72. Without this patch, bin\solr start fails for me on the lucene_solr_4_10 branch in the same way as in the issue description. With this patch, under both 32-bit 1.7.0_72 and 64-bit 1.7.0_25, the following worked for me: bin\solr start / bin\solr stop -all bin\solr start / bin\solr stop -p 8983 bin\solr start / bin\solr start (appropriate error printed) bin\solr start / bin\solr -i Committing shortly.
          Hide
          Steve Rowe added a comment -

          Committed to lucene_solr_4_10.

          Show
          Steve Rowe added a comment - Committed to lucene_solr_4_10.
          Hide
          ASF subversion and git services added a comment -

          Commit 1662596 from Steve Rowe in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1662596 ]

          SOLR-6693: bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME (merged branch_5x r1658426)

          Show
          ASF subversion and git services added a comment - Commit 1662596 from Steve Rowe in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1662596 ] SOLR-6693 : bin\solr.cmd doesn't support 32-bit JRE/JDK running on Windows due to parenthesis in JAVA_HOME (merged branch_5x r1658426)
          Hide
          Michael McCandless added a comment -

          Bulk close for 4.10.4 release

          Show
          Michael McCandless added a comment - Bulk close for 4.10.4 release

            People

            • Assignee:
              Steve Rowe
              Reporter:
              Jan Høydahl
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development