[ 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