[
https://issues.apache.org/jira/browse/SOLR-16571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645068#comment-17645068
]
David Smiley commented on SOLR-16571:
-------------------------------------
[~noblepaul], I didn't know there was such a watcher so I got a bit curious to
see what's going on. I did some git archeology and turned up that you added
this in SOLR-5200 / SOLR-6533. So the feature here is two-fold, one is the
general ability to add a ConfigSet watcher (it's a public method). But that
general ability is unused -- public method that isn't called (today). The
other part of it is that Solr by default will check to see if the ZNode to the
root of the conf dir for this configSet (not a file inside) is updated and
trigger an automatic reload of the core. *That* is news to me and I have
suspicions anyone is using it. Do you know if it's documented? As a quick
experiment, no-oped the underlying implementation and found that
org.apache.solr.handler.TestConfigReload failed, which was written to test this
feature.
org.apache.solr.cloud.TestPullReplicaErrorHandling#testCloseHooksDeletedOnReconnect
also fails but at a glance my suspicion is that it's presumptuous about
implementation details of how many close hooks exist because the feature we're
talking about will register one of these.
If we think people aren't likely using this and could simply issue a RELOAD
command (why not); let's deprecate and remove this stuff.
> Add Java system property for ZooKeeper config watch
> ---------------------------------------------------
>
> Key: SOLR-16571
> URL: https://issues.apache.org/jira/browse/SOLR-16571
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Nick Ginther
> Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Solr creates a ZooKeeper watch per-core. On nodes with a lot of cores, this
> results in a lot of ZK watches, and thus increased resource consumption. ZK
> config watches aren't strictly necessary, so we should be able to disable
> them if we want to. To remedy this, we should add a Java system property to
> disable the ZK config watch per core. The default behavior should still be to
> create a ZK config watch per core.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
