[
https://issues.apache.org/jira/browse/SOLR-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259834#comment-17259834
]
Houston Putman commented on SOLR-14999:
---------------------------------------
So we can't "deprecate" jetty.port really, since it's a variable used in the
Jetty XML. This would be possible if Solr owned the setup of Jetty, but there
is no way of putting multiple variables to read from in the jetty xml. (Aka,
use solr.port.listen -> solr.port -> jetty.port -> 8983, in that order). This
is a SIP already, SOLR-14361.
We could also have bin/solr do some smart renaming of variables, but not
everyone uses bin/solr.
Is "solr.port.listen" something we are ok punting on until later, or should we
wait to make the "solr.port.advertise" until we can make both changes? We could
also decide to make "solr.port.listen" a 9.0 thing, and make it explicitly
clear to everyone that the name has changed in the major version and they need
to use the new system property if they are not using bin/solr.
Personally, I think that "solr.port.advertise" is useful-enough on its own to
put into 8.8, and we can decide on how we want to change "jetty.port" to
"solr.port.listen" in the future.
> Add built-in option to advertise Solr with a different port than Jetty
> listens on.
> ----------------------------------------------------------------------------------
>
> Key: SOLR-14999
> URL: https://issues.apache.org/jira/browse/SOLR-14999
> Project: Solr
> Issue Type: Improvement
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the default settings in {{solr.xml}} allow the specification of one
> port, {{jetty.port}} which the bin/solr script provides from the
> {{SOLR_PORT}} environment variable. This port is used twice. Jetty uses it to
> listen for requests, and the clusterState uses the port to advertise the
> address of the Solr Node.
> In cloud environments, it's sometimes crucial to be able to listen on one
> port and advertise yourself as listening on another. This is because there is
> a proxy that listens on the advertised port, and forwards the request to the
> server which is listening to the jetty port.
> Solr already supports having a separate Jetty port and Live Nodes port
> (examples provided in the dev-list discussion linked below). I suggest that
> we add this to the default solr config so that users can use the default
> solr.xml in cloud configurations, and the solr/bin script will enable easy
> use of this feature.
> There has been [discussion on this exact
> problem|https://mail-archives.apache.org/mod_mbox/lucene-dev/201910.mbox/%3CCABEwPvGFEggt9Htn%3DA5%3DtoawuimSJ%2BZcz0FvsaYod7v%2B4wHKog%40mail.gmail.com%3E]
> on the dev list already.
> I propose the new system property to be used for {{hostPort}} in the
> solr.xml. I am open to changing the name, but to me it is more descriptive
> than {{hostPort}}.
> {{-Dsolr.port.advertise}} and {{SOLR_PORT_ADVERTISE}} (env var checked in
> bin/solr).
> The xml field {{<hostPort>}} would not be changed however, just the system
> property that is used to fill the value in the default {{solr.xml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
