CloudSolrClient: Remapping host & IP

[David Smiley <ds...@apache.org>]

Sometimes, the host & port that a Solr node is accessible at *within* the
SolrCloud cluster is different from one *outside* the cluster.

I recall this use-case at my last job in which the host name that was
exposed was not ideally chosen, even though it worked mostly but wasn't
reliable in startup/shutdown scenarios (involving k8s).  Sorry I don't
remember more. One important use-case I'm facing right now is Solr running
in Docker, with tests that want to use CloudSolrClient to be realistic.
Inside, Solr is running at localhost:8983 but from the outside, the random
port available to run the container is something else.  A work-around is to
fix/hard-code the port but that limits test parallelization to one, and may
conflict with Solr running on a developer workstation for other reasons.

I'm looking at CloudSolrClient and I'm seeing that a solution may be as
simple as extracting all calls to Utils.getBaseUrlForNodeName to some
plugable mechanism (details very TBD).  I haven't tried it yet; this is
just a straw-man.  Any thoughts on this and the general need?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: CloudSolrClient: Remapping host & IP

[David Smiley <ds...@apache.org>]

So far I'm getting success by customizing the HttpClient (with Gemini AI
telling me what to do).  Even though it feels like a hack, I think it's
better than messing with CloudSolrClient.  I could imagine making this hack
easier/supported for users through the CloudSolrClient builder when it
constructs the HttpClient but I don't know if we need to make it *that*
easy.  I suppose at the least, I could update javadocs on
withHttpClientBuilder to document this use-case.

Disclaimer: very preliminary success so far, and unfortunately I'm using
the Apache HttpClient but I imagine there'd be a similar mechanism for
Jetty HttpClient.

On Fri, Sep 19, 2025 at 2:03 PM David Smiley <ds...@apache.org> wrote:

> Sometimes, the host & port that a Solr node is accessible at *within* the
> SolrCloud cluster is different from one *outside* the cluster.
>
> I recall this use-case at my last job in which the host name that was
> exposed was not ideally chosen, even though it worked mostly but wasn't
> reliable in startup/shutdown scenarios (involving k8s).  Sorry I don't
> remember more. One important use-case I'm facing right now is Solr running
> in Docker, with tests that want to use CloudSolrClient to be realistic.
> Inside, Solr is running at localhost:8983 but from the outside, the random
> port available to run the container is something else.  A work-around is to
> fix/hard-code the port but that limits test parallelization to one, and may
> conflict with Solr running on a developer workstation for other reasons.
>
> I'm looking at CloudSolrClient and I'm seeing that a solution may be as
> simple as extracting all calls to Utils.getBaseUrlForNodeName to some
> plugable mechanism (details very TBD).  I haven't tried it yet; this is
> just a straw-man.  Any thoughts on this and the general need?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>