SOLR-18336: bin/solr.cmd start should wait only for the started Solr instance - #4710
Open
janhoy wants to merge 5 commits into
Open
SOLR-18336: bin/solr.cmd start should wait only for the started Solr instance#4710janhoy wants to merge 5 commits into
janhoy wants to merge 5 commits into
Conversation
On Windows, 'solr.cmd start' invoked 'status --max-wait-secs' without identifying the instance just started, causing the status tool to scan the PID directory and wait for every running Solr instance. Pass the port so only the newly started instance is waited for, matching the behavior of bin/solr on Linux. The status tool resolves the URL scheme (http/https) from the running process itself.
janhoy
marked this pull request as draft
August 4, 2026 23:25
Contributor
|
Seems reasonable.. and I guess a bats test woudn't have caught this since it's windows only... |
With SOLR_HOST_BIND set to a non-loopback address, Jetty does not listen on localhost, so the status tool could not reach the instance when waiting for startup. Parse the bind host from the process command line (like port and SSL already are) and use it in the local URL. Wildcard and loopback bind addresses still map to localhost, preserving existing URLs for default installs and keeping SSL hostname verification working with certificates issued for localhost.
The status tool's -p wait now re-scans for the process until the deadline instead of failing if the newly started process is not yet visible. The local URL for a process now prefers -Dsolr.host.advertise when set, falling back to the bind host, matching pre-10 behavior for non-loopback binds with SSL certificates issued for the advertised hostname.
…Port Collapse three near-identical sysprop-parsing pipelines into one helper, dropping the unreachable -Dsolr.jetty.host fallback (10.x scripts always translate the deprecated name to solr.host.bind before launch). Move the process wait loop into SolrProcessManager.waitForProcessOnPort, reusing the TimeOut utility. Start mock test processes in parallel.
janhoy
changed the title
janhoy
marked this pull request as ready for review
August 5, 2026 15:11
epugh
reviewed
Aug 6, 2026
epugh
left a comment
epugh
left a comment
Contributor
There was a problem hiding this comment.
This all looks great. I think my one problem is that we're solving windows issues in our java code, but we don't have great testing in our windows path... I'd love, if we believe this is viable code, and it appears to be, to apply this to the linux path as well, that way if bugs crop up, the theory is we'll see and fix them tjhat much sooner. For example, we could use a bats test if we wanted...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes https://issues.apache.org/jira/browse/SOLR-18336
The Windows start script now passes
-p <port>toSolrCLI status, so the start wait targets only the newly started instance instead of every PID file found.The status tool resolves the instance's URL from the running process's own command line: it prefers
-Dsolr.host.advertisewhen set, falls back to a non-loopback-Dsolr.host.bind, and maps loopback/wildcard binds tolocalhost. Since the process may not be visible in the process table immediately after launch, the tool re-scans until the--max-wait-secsdeadline instead of failing on the first miss.This gives the same behavior as 9.x, which built
--solr-urlfromSOLR_HOST(the advertised host) when set, else localhost: the wait connects to the advertised name — so SSL hostname verification against certificates issued for that name keeps working — and non-loopback binds (SOLR_HOST_BIND=10.0.x.x) no longer fail with a localhost connection error. As a bonus,bin/solr statusnow prints reachable URLs for such nodes too.PS: The Linux start script does not use SolrCLI for waiting for Solr, thus it was never affected. With these hardenings, we are perhaps soon ready to migrate the linux start script over to StatusTool as well.