[
https://issues.apache.org/jira/browse/SOLR-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353783#comment-15353783
]
Jan Høydahl commented on SOLR-9194:
-----------------------------------
I still don't understand why we're doing all this command option parsing in .sh
and .cmd, when we could have passed the whole input to SolrCLI.java and make
the logic there.
Well, I understand that currently we rely on parsing {{solr.in.sh|cmd}} for
various Java options like memory, port etc, but that file could be a properties
file parsed by Java, and then Java could fork a new child process calling Java
with all the correct options, not?
> Enhance the bin/solr script to perform file operations to/from Zookeeper
> ------------------------------------------------------------------------
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: SOLR-9194.patch, SOLR-9194.patch, SOLR-9194.patch,
> SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g.
> solr.xml, security.json, clusterprops.json. Who knows? Even
> <collection>/state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if
> someone else wanted to take it...
> I'm thinking the commands would be
> bin/solr zk -putfile -z <ensemble> -p <zookeeper path> -f <local file path>
> bin/solr zk -getfile -z <ensemble> -p <zookeeper path> -f <local file path>
> but I'm not wedded to those, all suggestions welcome.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
