[ 
https://issues.apache.org/jira/browse/SOLR-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17951411#comment-17951411
 ] 

Jason Gerlowski commented on SOLR-6629:
---------------------------------------

bq. A voice from the future

If it impacts scaling and makes the code harder to maintain, it'd be great to 
see it go.

But at least to uninitiated eyes, it looks like CollectionsChildWatcher is 
still in use and saves a number of ZK "exists" checks.  Any chance the voice 
from the future could explain *why* it's not necessary or what the alternative 
is for those places it's currently in-use? 😛

> Watch /collections zk node on all nodes
> ---------------------------------------
>
>                 Key: SOLR-6629
>                 URL: https://issues.apache.org/jira/browse/SOLR-6629
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>            Reporter: Shalin Shekhar Mangar
>            Assignee: Shalin Shekhar Mangar
>            Priority: Major
>             Fix For: 5.4, 6.0
>
>         Attachments: SOLR-6629-new.patch, SOLR-6629.patch, SOLR-6629.patch, 
> SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch
>
>
> The main clusterstate.json is refreshed/used as a poor substitute for 
> informing all nodes about new or deleted collections even when the collection 
> being created or deleted has state format > 1. When we move away from state 
> format 1 then we should do away with this workaround and start watching the 
> /collections zk node on all nodes.



--
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

Reply via email to