Solr
  1. Solr
  2. SOLR-6928

solr.cmd stop works only in english

    Details

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

      german windows 7

      Description

      in solr.cmd the stop doesnt work while executing 'netstat -nao ^| find /i "listening" ^| find ":%SOLR_PORT%"' so "listening" is not found.

      e.g. in german cmd.exe the netstat -nao prints the following output:

        Proto  Lokale Adresse         Remoteadresse          Status           PID
        TCP    0.0.0.0:80             0.0.0.0:0              ABHÖREN         4
      
      1. SOLR-6928.patch
        7 kB
        Jan Høydahl
      2. SOLR-6928.patch
        7 kB
        Timothy Potter
      3. SOLR-6928-lucene_solr_4_10.patch
        7 kB
        Steve Rowe

        Activity

        Hide
        Hoss Man added a comment -

        is there a windows batch file equivalent of "LANG" in unix?

        Show
        Hoss Man added a comment - is there a windows batch file equivalent of "LANG" in unix?
        Hide
        Jan Høydahl added a comment -

        Think this could be a solution http://channel9.msdn.com/Blogs/witastre/How-to-see-command-line-tools-output-in-English-on-East-Asian-Russian-and-Greek-language-of-Windows-

        john.work can you test typing the following command in your CMD window before executing bin\solr.cmd stop ?

        chcp 437
        
        Show
        Jan Høydahl added a comment - Think this could be a solution http://channel9.msdn.com/Blogs/witastre/How-to-see-command-line-tools-output-in-English-on-East-Asian-Russian-and-Greek-language-of-Windows- john.work can you test typing the following command in your CMD window before executing bin\solr.cmd stop ? chcp 437
        Hide
        Uwe Schindler added a comment - - edited

        This does not help it only changes the charset. The reason why this works for asian text is: if you change the code page to 437 (which is from old DOS days), the console is no longer able to output unicode characters. Because of that it can no longer use the default locale. A side effect is then that it uses English, because the command has no other chance to output something.

        On a German Windows the output stays German, because German perfectly fits into code page 437.

        In fact we would need to find a way to change the locale not just code page.

        Show
        Uwe Schindler added a comment - - edited This does not help it only changes the charset. The reason why this works for asian text is: if you change the code page to 437 (which is from old DOS days), the console is no longer able to output unicode characters. Because of that it can no longer use the default locale. A side effect is then that it uses English, because the command has no other chance to output something. On a German Windows the output stays German, because German perfectly fits into code page 437. In fact we would need to find a way to change the locale not just code page.
        Hide
        Jan Høydahl added a comment -

        Bummer! Windows is not that flexible. I see some ways to put a locale.txt on C:\ and then run some command, but I think it changes the locale for the whole computer and user may need to log in/out.

        Perhaps we cannot rely on parsing english output from tools, but craft some other way to detect a listening port

        Show
        Jan Høydahl added a comment - Bummer! Windows is not that flexible. I see some ways to put a locale.txt on C:\ and then run some command, but I think it changes the locale for the whole computer and user may need to log in/out. Perhaps we cannot rely on parsing english output from tools, but craft some other way to detect a listening port
        Hide
        Jan Høydahl added a comment -

        As a temp fix, bin/start could detect if we're on english windows in the start, and exit with a message and error code if stop is attempted.

        If we're not able to fix this for real before 5.0, we should perhaps add a NOTE paragraph to the RefGuide.

        Show
        Jan Høydahl added a comment - As a temp fix, bin/start could detect if we're on english windows in the start, and exit with a message and error code if stop is attempted. If we're not able to fix this for real before 5.0, we should perhaps add a NOTE paragraph to the RefGuide.
        Hide
        Uwe Schindler added a comment - - edited

        Yeah, I checked that out, too. You cannot change the locale without login/logout, and this would also affect user's other programs running.

        In fact, not all of the programs are dynamically localized with ".mui" files. Some of them (like xcopy) are only in one language (the one of the shipped OS). Also it is not guaranteed that the english locale is there at all - especially on desktop operating systems.

        I think we should place the listening port into a temp file (like Process IDs). We could also use the process ID like in Unix - Windows has that, too?

        Show
        Uwe Schindler added a comment - - edited Yeah, I checked that out, too. You cannot change the locale without login/logout, and this would also affect user's other programs running. In fact, not all of the programs are dynamically localized with ".mui" files. Some of them (like xcopy) are only in one language (the one of the shipped OS). Also it is not guaranteed that the english locale is there at all - especially on desktop operating systems. I think we should place the listening port into a temp file (like Process IDs). We could also use the process ID like in Unix - Windows has that, too?
        Hide
        Jan Høydahl added a comment -

        Why do we need to grep for "listening" in the first place? Could there be multiple entries of :8983 in the netstat output if we don't?

        Show
        Jan Høydahl added a comment - Why do we need to grep for "listening" in the first place? Could there be multiple entries of :8983 in the netstat output if we don't?
        Hide
        Uwe Schindler added a comment -

        There could be UDP ports open or half open connections in wait state. In Linux you can restrict this by command line options (to only show LISTEN), but Windows has no such option - as far as I see. The standard to show listening ports with protocol TCP on Linux is "netstat -tl" (t=tcp/tcp6, l=listen).

        Show
        Uwe Schindler added a comment - There could be UDP ports open or half open connections in wait state. In Linux you can restrict this by command line options (to only show LISTEN), but Windows has no such option - as far as I see. The standard to show listening ports with protocol TCP on Linux is "netstat -tl" (t=tcp/tcp6, l=listen).
        Hide
        Jan Høydahl added a comment -

        Ok, this should do it:

        netstat -nao | find /i "TCP" | find /i ":8983"
        

        One related edit is that the find command should look for ":8983 " (with a space after the port number) to avoid matching other ports, e.g. the following stop command would select two lines in netstat output since :1234 will also match :12345

        solr start -p 1234
        solr start -p 12345
        solr stop -p 1234
        
        Show
        Jan Høydahl added a comment - Ok, this should do it: netstat -nao | find /i "TCP" | find /i ":8983" One related edit is that the find command should look for ":8983 " (with a space after the port number) to avoid matching other ports, e.g. the following stop command would select two lines in netstat output since :1234 will also match :12345 solr start -p 1234 solr start -p 12345 solr stop -p 1234
        Hide
        Timothy Potter added a comment -

        awesome suggestion Jan! testing your idea now and will get committed for 5

        Show
        Timothy Potter added a comment - awesome suggestion Jan! testing your idea now and will get committed for 5
        Hide
        Timothy Potter added a comment -

        Here's a patch that builds upon Jan's, but required checking for PID==0 because it was still finding something that wasn't listening:

        Proto Local Address Foreign Address State PID
        TCP 127.0.0.1:49204 127.0.0.1:8983 TIME_WAIT 0

        According to the docs, the PID 0 is for a pseudo-idle process so the script could ignore those and keep looping to find the actual listening process.

        This patch works well on English Windows ... I don't have access to a German Windows box, can someone test please?

        Show
        Timothy Potter added a comment - Here's a patch that builds upon Jan's, but required checking for PID==0 because it was still finding something that wasn't listening: Proto Local Address Foreign Address State PID TCP 127.0.0.1:49204 127.0.0.1:8983 TIME_WAIT 0 According to the docs, the PID 0 is for a pseudo-idle process so the script could ignore those and keep looping to find the actual listening process. This patch works well on English Windows ... I don't have access to a German Windows box, can someone test please?
        Hide
        Jan Høydahl added a comment -

        Slightly improved patch

        • No need for case insensitive find
        • Require a space after port number to avoid false match
        Show
        Jan Høydahl added a comment - Slightly improved patch No need for case insensitive find Require a space after port number to avoid false match
        Hide
        ASF subversion and git services added a comment -

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

        SOLR-6928: solr.cmd stop works only in english

        Show
        ASF subversion and git services added a comment - Commit 1653699 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1653699 ] SOLR-6928 : solr.cmd stop works only in english
        Hide
        ASF subversion and git services added a comment -

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

        SOLR-6928: solr.cmd stop works only in english

        Show
        ASF subversion and git services added a comment - Commit 1653700 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1653700 ] SOLR-6928 : solr.cmd stop works only in english
        Hide
        ASF subversion and git services added a comment -

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

        SOLR-6928: solr.cmd stop works only in english

        Show
        ASF subversion and git services added a comment - Commit 1653701 from Timothy Potter in branch 'dev/branches/lucene_solr_5_0' [ https://svn.apache.org/r1653701 ] SOLR-6928 : solr.cmd stop works only in english
        Hide
        Uwe Schindler added a comment -

        Hi,
        I can confirm it seems to stop the right server on German Windows 7.
        Although I see strange messages in the console on startup/shutdown:

        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd  start -p 8984
        Backing up C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr.log
                1 Datei(en) verschoben.
        Backing up C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr_gc.log
                1 Datei(en) verschoben.
        
        Starting Solr on port 8984 from C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server
        
        Zugriff verweigert
        
        Direct your Web browser to http://localhost:8984/solr to visit the Solr Admin UI
        
        
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>SLF4J: Class path contains multiple SLF4J bindings.
        SLF4J: Found binding in [jar:file:/C:/Users/Uwe%20Schindler/Projects/lucene/trunk-lusolr1/solr/server/lib/ext/slf4j-log4j12-1.7.6.ja
        r!/org/slf4j/impl/StaticLoggerBinder.class]
        SLF4J: Found binding in [jar:file:/C:/Users/Uwe%20Schindler/Projects/lucene/trunk-lusolr1/solr/server/lib/ext/slf4j-log4j12-1.7.7.ja
        r!/org/slf4j/impl/StaticLoggerBinder.class]
        SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
        SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
        
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd  stop -p 8984
        Stopping Solr running on port 8984
        Das System kann den angegebenen Pfad nicht finden.
        
        Gewartet wird 0 Sekunden. Weiter mit beliebiger Taste...
        
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd  stop -p 8984
        No Solr found running on port 8984
        
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>
        
        Show
        Uwe Schindler added a comment - Hi, I can confirm it seems to stop the right server on German Windows 7. Although I see strange messages in the console on startup/shutdown: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd start -p 8984 Backing up C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr.log 1 Datei(en) verschoben. Backing up C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr_gc.log 1 Datei(en) verschoben. Starting Solr on port 8984 from C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server Zugriff verweigert Direct your Web browser to http://localhost:8984/solr to visit the Solr Admin UI C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/Users/Uwe%20Schindler/Projects/lucene/trunk-lusolr1/solr/server/lib/ext/slf4j-log4j12-1.7.6.ja r!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/Users/Uwe%20Schindler/Projects/lucene/trunk-lusolr1/solr/server/lib/ext/slf4j-log4j12-1.7.7.ja r!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin> C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin> C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd stop -p 8984 Stopping Solr running on port 8984 Das System kann den angegebenen Pfad nicht finden. Gewartet wird 0 Sekunden. Weiter mit beliebiger Taste... C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr.cmd stop -p 8984 No Solr found running on port 8984 C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>
        Hide
        Uwe Schindler added a comment -

        In addition, "ant run-example" is broken on windows, which makes development harder for me:

        run-example:
        
        BUILD FAILED
        C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\build.xml:66: Execute failed: java.io.IOException: Cannot run program "C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin\solr": CreateProcess error=193, %1 ist keine zulässige Win32-Anwendung
                at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
                at java.lang.Runtime.exec(Runtime.java:620)
                at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec(Execute.java:862)
                at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:481)
                at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:495)
                at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:631)
                at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672)
                at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498)
                at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
                at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.lang.reflect.Method.invoke(Method.java:483)
                at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
                at org.apache.tools.ant.Task.perform(Task.java:348)
                at org.apache.tools.ant.Target.execute(Target.java:392)
                at org.apache.tools.ant.Target.performTasks(Target.java:413)
                at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
                at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
                at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
                at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
                at org.apache.tools.ant.Main.runBuild(Main.java:811)
                at org.apache.tools.ant.Main.startAnt(Main.java:217)
                at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
                at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
        Caused by: java.io.IOException: CreateProcess error=193, %1 ist keine zulõssige Win32-Anwendung
                at java.lang.ProcessImpl.create(Native Method)
                at java.lang.ProcessImpl.<init>(ProcessImpl.java:386)
                at java.lang.ProcessImpl.start(ProcessImpl.java:137)
                at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
                ... 23 more
        
        Total time: 4 minutes 0 seconds
        

        I think the problem is that the ant task should use "solr.cmd" if it detects windows.

        Show
        Uwe Schindler added a comment - In addition, "ant run-example" is broken on windows, which makes development harder for me: run-example: BUILD FAILED C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\build.xml:66: Execute failed: java.io.IOException: Cannot run program "C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin\solr": CreateProcess error=193, %1 ist keine zulässige Win32-Anwendung at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at java.lang.Runtime.exec(Runtime.java:620) at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec(Execute.java:862) at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:481) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:495) at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:631) at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:811) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: java.io.IOException: CreateProcess error=193, %1 ist keine zulõssige Win32-Anwendung at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.<init>(ProcessImpl.java:386) at java.lang.ProcessImpl.start(ProcessImpl.java:137) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) ... 23 more Total time: 4 minutes 0 seconds I think the problem is that the ant task should use "solr.cmd" if it detects windows.
        Hide
        Jan Høydahl added a comment -

        I see also that my patch update missed a few places to insert a space after port number, in find ":!SOME_SOLR_PORT!"

        Show
        Jan Høydahl added a comment - I see also that my patch update missed a few places to insert a space after port number, in find ":!SOME_SOLR_PORT!"
        Hide
        Uwe Schindler added a comment -

        I opened another issue (SOLR-7016) for an "run-example" brokenness with sapces in installation path. I already fixed the ant task to use sold.cmd on windows.

        Show
        Uwe Schindler added a comment - I opened another issue ( SOLR-7016 ) for an "run-example" brokenness with sapces in installation path. I already fixed the ant task to use sold.cmd on windows.
        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 - - edited

        Reopen for backport to 4.10.4

        Show
        Steve Rowe added a comment - - edited Reopen for backport to 4.10.4
        Hide
        Steve Rowe added a comment -

        Patch for the lucene_solr_4_10 branch, I'll test (on English Win 7) - if anybody else can test on a non-English locale, that would be helpful.

        Show
        Steve Rowe added a comment - Patch for the lucene_solr_4_10 branch, I'll test (on English Win 7) - if anybody else can test on a non-English locale, that would be helpful.
        Hide
        Steve Rowe added a comment - - edited

        I tested the patched 4.10 branch on English Win 7, Oracle JVM 1.7.0_60, with:

        • bin\solr start / bin\solr stop -all
        • bin\solr start / bin\solr stop -p 8983
        • bin\solr start / bin\solr -i

        All of these work.

        Also got correct error message from bin\solr start / bin\solr start.

        There is a problem with this approach, though, very likely on all branches: the modified test against netstat output also matches non-listening entries, so e.g. when using the admin UI, non-listening connections from my web browser linger after the Solr jetty has died, and the stop code goes into a loop where it thinks there is still an open Solr process, but can't find the corresponding .port file. Eventually, the loop terminates (after ~6 iterations in my tests). I'll make a new issue.

        I'll commit this to the lucene_solr_4_10 branch now.

        Show
        Steve Rowe added a comment - - edited I tested the patched 4.10 branch on English Win 7, Oracle JVM 1.7.0_60, with: bin\solr start / bin\solr stop -all bin\solr start / bin\solr stop -p 8983 bin\solr start / bin\solr -i All of these work. Also got correct error message from bin\solr start / bin\solr start . There is a problem with this approach, though, very likely on all branches: the modified test against netstat output also matches non-listening entries, so e.g. when using the admin UI, non-listening connections from my web browser linger after the Solr jetty has died, and the stop code goes into a loop where it thinks there is still an open Solr process, but can't find the corresponding .port file. Eventually, the loop terminates (after ~6 iterations in my tests). I'll make a new issue. I'll commit this to the lucene_solr_4_10 branch now.
        Hide
        ASF subversion and git services added a comment -

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

        SOLR-6928: solr.cmd stop works only in english (merged branch_5x r1653700)

        Show
        ASF subversion and git services added a comment - Commit 1662543 from Steve Rowe in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1662543 ] SOLR-6928 : solr.cmd stop works only in english (merged branch_5x r1653700)
        Hide
        Steve Rowe added a comment -

        Committed on lucene_solr_4_10.

        There is a problem with this approach, though, very likely on all branches: the modified test against netstat output also matches non-listening entries, so e.g. when using the admin UI, non-listening connections from my web browser linger after the Solr jetty has died, and the stop code goes into a loop where it thinks there is still an open Solr process, but can't find the corresponding .port file. Eventually, the loop terminates (after ~6 iterations in my tests). I'll make a new issue.

        I see Timothy Potter fixed this as part of SOLR-7016, which I'm going to backport next. I couldn't get this to reproduce on trunk, because processes not listed by netstat as on IP 0.0.0.0 (where Solr's jetty binds) are ignored after SOLR-7016.

        Show
        Steve Rowe added a comment - Committed on lucene_solr_4_10. There is a problem with this approach, though, very likely on all branches: the modified test against netstat output also matches non-listening entries, so e.g. when using the admin UI, non-listening connections from my web browser linger after the Solr jetty has died, and the stop code goes into a loop where it thinks there is still an open Solr process, but can't find the corresponding .port file. Eventually, the loop terminates (after ~6 iterations in my tests). I'll make a new issue. I see Timothy Potter fixed this as part of SOLR-7016 , which I'm going to backport next. I couldn't get this to reproduce on trunk, because processes not listed by netstat as on IP 0.0.0.0 (where Solr's jetty binds) are ignored after SOLR-7016 .
        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:
            john.work
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development