[
https://issues.apache.org/jira/browse/SOLR-18026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18044573#comment-18044573
]
Jan Høydahl edited comment on SOLR-18026 at 12/12/25 1:36 AM:
--------------------------------------------------------------
I think we can conclude that the lack of JSM in JRE23+ is the reason for the
diff. Claude and I did some testing.
The test sets System.setProperty("host", "localhost") to simulate setting a
host name, expecting it to be used as host by solr.xml. But since this happens
after EnvUtils static initialization, it is never translated to
solr.host.advertise, which is used by solr.xml, and thus solr.xml falls back to
empty string for "host", and solr then falls back to InetAddress.getLocalHost()
when deciding what address to listen on and put into Zookeeper live_nodes. And
since InetAddress.getLocalHost() returns loopback under JSM and real IP when
not under JSM, Solr will bind to different host names, and then connecting to
localhost won't work, as the test does.
h3. Why Security Manager "Fixes" It (JDK 21 default)
Security Manager restricts network operations:
1. InetAddress.getLocalHost() can't do normal network lookup → returns 127.0.0.1
2. NetworkInterface.getInetAddresses() blocked → returns only loopback IPs
3. Node advertises as 127.0.0.1:port_solr
4. CLI connects to [http://localhost:port] → also 127.0.0.1
5. Match! Test passes ✅
h3. Why JDK 23+ Fails (No Security Manager)
No Security Manager = unrestricted network access:
1. InetAddress.getLocalHost() works normally → returns 192.168.0.116
2. Node advertises as 192.168.0.116:port_solr
3. CLI connects to [http://localhost:port] → resolves to 127.0.0.1
4. Mismatch! "No live SolrServers available" ❌
I do believe this is mainly an issue for our test framework, we shuold likely
be consistent in using solr.host.advertise everywhere to avoid surprises.
The start script injects user-selected hostname as before, both under JSM and
without.
The difference is if the user starts bin/solr without specifying a host name,
then under JSM it will advertise as 127.0.0.1 and work locally only, but when
JSM is disabled, it will advertise as whatever real IP address Java decides to
give it. Which I suppose may or may not be what users expect when connecting
from different hosts. Perhaps we should consider defaulting to a static
127.0.0.1 or 0.0.0.0 instead of doing magic lookups, and require/expect users
to be explicit and always configure concrete host names to bind to and
advertise?
was (Author: janhoy):
I think we can conclude that the lack of JSM in JRE23+ is the reason for the
diff. Claude and I did some testing.
The test sets System.setProperty("host", "localhost") to simulate setting a
host name, expecting it to be used as host by solr.xml. But since this happens
after EnvUtils static initialization, it is never translated to
solr.host.advertise, which is used by solr.xml, and thus solr.xml falls back to
empty string for "host", and solr then falls back to InetAddress.getLocalHost()
when deciding what address to listen on and put into Zookeeper live_nodes. And
since InetAddress.getLocalHost() returns loopback under JSM and real IP when
not under JSM, Solr will bind to different host names, and then connecting to
localhost won't work, as the test does.
h3. Why Security Manager "Fixes" It (JDK 21 default)
Security Manager restricts network operations:
1. InetAddress.getLocalHost() can't do normal network lookup → returns 127.0.0.1
2. NetworkInterface.getInetAddresses() blocked → returns only loopback IPs
3. Node advertises as 127.0.0.1:port_solr
4. CLI connects to [http://localhost:port] → also 127.0.0.1
5. Match! Test passes ✅
h3. Why JDK 23+ Fails (No Security Manager)
No Security Manager = unrestricted network access:
1. InetAddress.getLocalHost() works normally → returns 192.168.0.116
2. Node advertises as 192.168.0.116:port_solr
3. CLI connects to [http://localhost:port] → resolves to 127.0.0.1
4. Mismatch! "No live SolrServers available" ❌
I do believe this is mainly an issue for our test framework. The start script
will inject user-configured host name, and when solr.xml uses the "host"
property from "solr.host.advertise" (or even the deprecated "host"), it will
advertise as that name also in ZK. But if solr.xml "host" falls back to empty
string since "solr.host.advertise" is not set, the fallback of using
InetAddress.getLocalHost() will resolve to a real IP-address when not using
JSM, which is probably OK if user has not explicitly set a stable host name.
> TestSolrCLIRunExample fails on jdk25 (and jdk24?)
> -------------------------------------------------
>
> Key: SOLR-18026
> URL: https://issues.apache.org/jira/browse/SOLR-18026
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Assignee: Eric Pugh
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We've recently seen a high number (44%) of jenkins failures from all 4 tests
> methods in TestSolrCLIRunExample.
> These failure seem to be exclusive to Uwe's jenkins box and based on a quick
> skim of the job descriptions that pass (vs the ones that fail) they only seem
> to fail when an (alt) jdk > 23 is used.
> I can reproduce these failures when setting my {{RUNTIME_JAVA_HOME}} env var
> to point to jdk25.
> Git bisect indicates that the failure was introduced by SOLR-15442 (which was
> a while ago -- the recency of the jenkins failures may be due to recent
> changes in how often Uwe's box runs Solr tests with alt jdks)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
