[
https://issues.apache.org/jira/browse/SOLR-14446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095850#comment-17095850
]
David Smiley commented on SOLR-14446:
-------------------------------------
Yes, this would be helpful. We shouldn't just address this one spot but also
the other place(s) where the files are uploaded.
https://github.com/apache/lucene-solr/blob/5e6d91eec082d158abcf9338ff0982eb20b4d30b/solr/solrj/src/java/org/apache/solr/common/cloud/ZkMaintenanceUtils.java#L278
(used to bootstrap ZK with the default configset, and perhaps used elsewhere)
There should probably be one utility method to do this that takes a Collection
of the data so that we have one place to maintain.
This will be nice change but I think just one piece of a two-piece puzzle.
Above is the write-side. On the read-side, due to eventual consistency, we
need to somewhere add a catch and retry mechanism if an expected file is not
present. But before retrying, call zookeeper.sync ( FYI: SOLR-14425 ). This
mechanism might be in ZkSolrResourceLoader, perhaps.
> Upload configset should use ZkClient.multi()
> --------------------------------------------
>
> Key: SOLR-14446
> URL: https://issues.apache.org/jira/browse/SOLR-14446
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Priority: Major
>
> Based on a private discussion with [~dsmiley] and [~dragonsinth] for
> SOLR-14425, it occurred to me that our configset upload is a loop over all
> files in a configset and individual writes.
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java#L184]
>
> It might make sense to use ZkClient.multi() here so that collection creation
> doesn't need to guess whether all files of the configset made it into the ZK
> or not (they will either all be there, or none at all).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
