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 <[email protected]> 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 >
