SOLR-17864: Migrate System Properties (part ocho)#3625
Conversation
github-actions
bot
added
documentation
…icit boolean. There is a chance that zkRun=blahblah is a thing, but I don't believe it. Maybe around port setting SolrZkServer. injectServers, but it may also just be dead code path.
Take advantage of standarized naming to simplify bin/solr scripts too.
github-actions
bot
added
docker
|
@gerlowskija remember when we hacked around with |
solr/bin/solr.in.cmd
Outdated
| REM set SOLR_JETTY_HOST=127.0.0.1 | ||
| REM Sets the network interface the Embedded ZK binds to. | ||
| REM set SOLR_ZK_EMBEDDED_HOST=127.0.0.1 | ||
| REM set SOLR_ZOOKEEPER_SERVER_EMBEDDED_HOST=127.0.0.1 |
There was a problem hiding this comment.
why put the word "embedded" in there? "server" implies embedded; it refers to the ZK server that Solr is running itself, embedded.
I could see swapping SERVER for EMBEDDED though... it would be clearer.
There was a problem hiding this comment.
We do want to keep this environmental name the same as the system property, so SOLR_ZOOKEEPER_EMBEDDED_HOST so we get the magic translation and don't need to pass it in expliiclty to Solr...
There was a problem hiding this comment.
I understand that; they need to be consistent for EnvUtils to work.
I'm discussing what the name should be (which will look a certain way when expressed as an env var vs system property).
| @@ -255,10 +255,11 @@ public String toString() { | |||
| private final Map<String, String> replicasInLeaderInitiatedRecovery = new HashMap<>(); | |||
|
|
|||
| // This is an expert and unsupported development mode that does not create | |||
There was a problem hiding this comment.
IMO we should drop this entirely. I've never heard of it and doesn't really sound useful TBH. Why run Solr that only runs ZK (that is confusing BTW!) when one could run ZK via Docker? Docker makes running anything easy in a developer workstation scenario, which is what this feature here is for.
CC @markrmiller
There was a problem hiding this comment.
I will take a stab at removing, but if we want to restore it'll be the matter of rolling back a single commit!
There was a problem hiding this comment.
Done in #1225833196dea24f413abbc3cc3fbef3d5b769fb
| solr.zookeeper.server.confdir=zk.server.conf.dir | ||
| solr.zookeeper.server.datadir=zk.server.data.dir | ||
| solr.zookeeper.server.enabled=zk.run | ||
| solr.zookeeper.server.embedded.host=solr.zk.embedded.host |
There was a problem hiding this comment.
ah; only this one did you put "embedded". again; don't need both "server" and "embedded"; pick one consistently for the set of running and embedded ZK server.
There was a problem hiding this comment.
I guess i can see an argument for ".server" being for zookeeper server related topics, and then ".embedded" for settings specfic to an embedded ZK...
There was a problem hiding this comment.
That is the same thing. There is no distinction. Solr only runs the server embedded; Solr doesn't run ZK separately. A user probably will but not Solr. These "server" props listed (like confdir) only applies to embedding ZK. In theory we might decide to fork a process to run another JVM for ZK... that would then not be "embedded". I could go either way on standardizing on "server" or "embedded" but I definitely propose we pick one.
There was a problem hiding this comment.
I think I missed a rename in the mapping file...
There was a problem hiding this comment.
Never mind, I just checked and the mapping file has the correct names.
epugh
changed the title
2 participants
https://issues.apache.org/jira/browse/SOLR-17864
solr.prs.default
enable.update.log
zk.server.conf.dir
zk.server.data.dir
zk.run
solr.zk.embedded.host
zk.run.only