[
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:30 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. 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.
was (Author: janhoy):
I think we can conclude that the lack of JSM in JRE23+ is the reason for the
diff. Here is Claude's writeup, we did an explicit test of Java's
{{InetAddress.getLocalHost()}} behaviour with and without JSM, and it is
{*}DIFFERENT{*}. Analysis by Claude:
The test sets System.setProperty("host", "localhost") but this happens after
EnvUtils static initialization. The deprecated property
mapping only runs during initialization, so solr.host.advertise never gets set.
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 always inject correct 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]
