[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417721#comment-17417721
]
Christine Poerschke commented on SOLR-7642:
-------------------------------------------
(Replying to non-code-detail pull request discussion here since there's already
other discussion details above and it might be helpful to have it mostly in one
place?)
----
[~houstonputman] commented on the above-mentioned
[apache/solr/pull/298|https://github.com/apache/solr/pull/298#issuecomment-921954381]
request:
{quote}Can we add this add an optional Env Var as well?
{quote}
Makes sense to me. Having (say) a {{ZK_CREATE_CHROOT}} would be consistent with
the existing {{ZK_HOST}} and {{ZK_CLIENT_TIMEOUT}} variables, though maybe
slightly odd to map that as {{-DcreateZkChroot=$ZK_CREATE_CHROOT}} on the
command line.
----
[~epugh] commented on the above-mentioned
[apache/solr/pull/298|https://github.com/apache/solr/pull/298#issuecomment-921966326]
request:
{quote}This will make life easier when I run mutliple versions of Solr on a
single ZK cluster! Out of curiosity, would you ever NOT want it to be
autocreated? Is adding a switch that opts in the right way? What if it was a
switch to opt out of autocreate?
{quote}
Good question w.r.t. opt-in vs. opt-out. I have no strong view either way:
opt-in could be viewed as a maintaining backwards compatibility or as more
guarding against accidental zknode creation; opt-out could be viewed as more
user friendly except maybe for the interaction with the {{bootstrap_conf[dir]}}
options i.e. what if the bootstrap option implies "yes please create the
chroot" but the opt-out option states "no you may not create the chroot"?
[~epugh] - did you have a specific opt-out switch name in mind perhaps?
> Should launching Solr in cloud mode using a ZooKeeper chroot create the
> chroot znode if it doesn't exist?
> ---------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
> Issue Type: Improvement
> Reporter: Timothy Potter
> Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch,
> SOLR-7642.patch, SOLR-7642_tag_7.5.0.patch,
> SOLR-7642_tag_7.5.0_proposition.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper
> connection string that includes a chroot leads to the following
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
> is that some violation of using a chroot?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
