[ 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