Solr jetty.port vs hostPort and host vs jetty.host

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Solr jetty.port vs hostPort and host vs jetty.host

david.w.smiley@gmail.com
While using MiniSolrCloudCluster on another project with a solr.xml that looks like the standard solr.xml, I ran into some problems.

The default solr.xml has a solrCloud element with these elements:
<str name="host">${host:}</str>
<int name="hostPort">${jetty.port:8983}</int>
<str name="hostContext">${hostContext:solr}</str>
And MiniSolrCloudCluster.DEFAULT_CLOUD_SOLR_XML, a string literal, has the equivalent of this:
<str name="host">127.0.0.1</str>
<int name="hostPort">${hostPort:8983}</int>
<str name="hostContext">${hostContext:solr}</str>
Notice the system property for the <hostPort> element is either "jetty.port" or "hostPort".  I submit that the system properties used here ought to be consistent.  So for example do away with jetty.port in lieu of hostPort given what appears more natural and consistent here.  This "hostPort" System property is used in a bunch of places in tests.  I've also seen a jetty.host lingering somewhere in some jetty xml files.

Also notice that the default solr.xml "host" has an empty string default, and AFAICT this is not equivalent to 127.0.0.1.

Any thoughts on this from folks in terms of understanding if/why we can't do this, or why this inconsistency is this way today?
Two relevant issues:

~ David Smiley
Apache Lucene/Solr Search Developer
Reply | Threaded
Open this post in threaded view
|

Re: Solr jetty.port vs hostPort and host vs jetty.host

Houston Putman
Thanks for pointing this out David.

I was confused about the difference between the two when I tried to make solr work with kubernetes networking. From my understanding now, "jetty.port" is the actual port that the jetty solr server listens on. "hostPort" is the port that the solr node advertises itself as, since the sole nodeName is just the host and port. This allowed me to run solr actually listening on port 8983, but advertising itself as listening on port 80. Then kubernetes services could map port 80 to port 8983.

I'm not sure if this is the official distinction between "hostPort" and "jetty.port", but it's worked for us. I would really like to keep this functionality available (I was very surprised to see it was possible when I first found it), because using solr within kubernetes will be harder without it.

- Houston

On Tue, Oct 8, 2019 at 1:44 PM David Smiley <[hidden email]> wrote:
While using MiniSolrCloudCluster on another project with a solr.xml that looks like the standard solr.xml, I ran into some problems.

The default solr.xml has a solrCloud element with these elements:
<str name="host">${host:}</str>
<int name="hostPort">${jetty.port:8983}</int>
<str name="hostContext">${hostContext:solr}</str>
And MiniSolrCloudCluster.DEFAULT_CLOUD_SOLR_XML, a string literal, has the equivalent of this:
<str name="host">127.0.0.1</str>
<int name="hostPort">${hostPort:8983}</int>
<str name="hostContext">${hostContext:solr}</str>
Notice the system property for the <hostPort> element is either "jetty.port" or "hostPort".  I submit that the system properties used here ought to be consistent.  So for example do away with jetty.port in lieu of hostPort given what appears more natural and consistent here.  This "hostPort" System property is used in a bunch of places in tests.  I've also seen a jetty.host lingering somewhere in some jetty xml files.

Also notice that the default solr.xml "host" has an empty string default, and AFAICT this is not equivalent to 127.0.0.1.

Any thoughts on this from folks in terms of understanding if/why we can't do this, or why this inconsistency is this way today?
Two relevant issues:

~ David Smiley
Apache Lucene/Solr Search Developer