[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18029152#comment-18029152
]
David Smiley commented on SOLR-17712:
-------------------------------------
[~ilan] , [in the dev
list|https://lists.apache.org/thread/szo8gh3y8c8zf6s7n0noqfjtncrd6dxd], you
raised a concern that (simply) changing this default:
bq. ... then creating a collection will be slower. We likely want to group the
replica creation for a new collection always, and then wait (or not wait) for
all of them to be visible.
CreateCollectionCmd will [create the replicas in
parallel|https://github.com/apache/solr/blob/05eb458609ae07e706cfcc3916d3c2c2d2c4f352/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L414].
I ran
`org.apache.solr.cloud.CollectionsAPISolrJTest#testCreateAndDeleteCollection`
with tracing using a local tracing server and the 4 replicas (2 shards, 2
replicationFactor) began at the same time, 2 completing quickly and 2 taking
longer. I didn't notice a material difference with waitForFinalState, also
checking on and off this branch. But this wasn't a collection-creation
benchmark; just a cold JVM with tracing. Nonetheless I'd expect _some_ small
difference since we are waiting for the final state, after all.
> SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
> ----------------------------------------------------------------------
>
> Key: SOLR-17712
> URL: https://issues.apache.org/jira/browse/SOLR-17712
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
> Labels: newdev, pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Collection creation has an optional parameter
> [waitForFinalState|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> :
> {quote}If {{{}true{}}}, the request will complete only when all affected
> replicas become active. The default is {{{}false{}}}, which means that the
> API will return the status of the single action, which may be before the new
> replica is online and active.{quote}
> Wouldn’t a caller of a command (any command to anything; whatever) generally
> expect that the command has completed when a command returns? I question the
> default choice of this parameter. I believe it pre-dated the more general
> “async” support of collection commands.
>
> Proposal: remove it. Internal logic should behave as if it's "true".
>
> Come to think of it, I see this in quite a number of other commands involving
> replica creations too.
> First baby step (individual PR) might simply be to change the default and
> wait some weeks through tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
