[
https://issues.apache.org/jira/browse/SOLR-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069577#comment-14069577
]
Timothy Potter commented on SOLR-6264:
--------------------------------------
Yes, we do, which is why this is tricky to see ;-) The
SolrCmdDistributor.distribCommit has a for loop that calls submit:
for (Node node : nodes) {
submit(new Req(cmd.toString(), node, uReq, false));
}
The submit uses a different CUSS of course, but the for loop is blocked because
the "async" submit is actually sync because ConcurrentUpdateSolrServer skips
the runners part if it's a commit. I only stumbled upon this by looking at
timestamp of requests and realized they were running serially and then
scratched my head a bit because I know StreamingSolrServers and CUSS pretty
well at this point.
I think it is true for commits too.
> optimize with waitSearcher=true leads to serial execution across all replicas
> -----------------------------------------------------------------------------
>
> Key: SOLR-6264
> URL: https://issues.apache.org/jira/browse/SOLR-6264
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Timothy Potter
>
> Regardless of whether one agrees with optimizing, when you execute an
> optimize request using waitSearcher=true, the requests from the controller
> node are sent to each replica in the collection serially.
> You can send the optimize command to the update handler for a collection to
> any node in the cluster. For instance, if I had a collection named "foo":
> curl -i -v http://localhost:8984/solr/foo/update --data-binary '<optimize
> maxSegments="1" waitSearcher="true"/>' -H 'Content-type:application/xml'
> The node that receives this request will collect the URL for all "live"
> replicas in the collection (not just leaders) (see
> DistributedUpdateProcessor#getCollectionUrls) and then forward the commit
> request to each of them. On the surface, the code looks like it forwards the
> request asynchronously to all replicas. However, this is not actually what
> happens; the commit requests to each replica in the collection will be
> processed serially when using waitSearcher=true (because
> ConcurrentUpdateSolrServer's background queue processing is by-passed for
> commits).
> Bottom-line, if you request the collection to be optimized, the request gets
> forwarded around as you'd expect but is done synchronously so can take a long
> time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
