[
https://issues.apache.org/jira/browse/SOLR-14446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383692#comment-17383692
]
Mark Robert Miller edited comment on SOLR-14446 at 7/20/21, 1:46 AM:
---------------------------------------------------------------------
This is also just very slow as is, which multi also acts as a drastic
improvement on.
The async API should also always be considered whenever considering the use of
multi.
The are pluses and minuses to either approach, but the performance is
essentially identical (a multi or pipelining a series of async calls and then
waiting).
With multi, you do get the atomicity - everything does exactly what you asked
for or fails and you try again. This is often overkill except for very specific
cases though.
If you went with async here instead of multi as an example: lets say you are
doing a config update but all the files are new except one. Instead of having
to reupload everything in another attempt (say you just tried to create
everything on attempt 1), you can see all the new files succeed, that the one
file existed, and just update that one file in step 2.
Not recommending an approach here, just FYI.
was (Author: markrmiller):
This is also just very slow as is, which multi also acts as a drastic
improvement on.
The async API should also always be considered whenever considering the use of
multi.
The are pluses and minuses to either approach, but the performance is
essentially identical (a multi or pipelining a series of async calls and then
waiting).
With multi, you do get the atomicity - everything does exactly what you asked
for or fails and you try again. This is often overkill exception for very
specific cases though.
If you went with async here instead of multi as an example:,lets say you are
doing a config update but all the files are new except one. Instead of having
to reupload everything in another attempt (say you just tried to create
everything on attempt 1), you can see all the new files succeed, that the one
file existed, and just update that one file in step 2.
Not recommending an approach here, just FYI.
> Upload configset should use ZkClient.multi()
> --------------------------------------------
>
> Key: SOLR-14446
> URL: https://issues.apache.org/jira/browse/SOLR-14446
> Project: Solr
> Issue Type: Improvement
> 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...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
