[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116158#comment-18116158
]
David Smiley commented on SOLR-17712:
-------------------------------------
[~serhiybzhezytskyy] [~aumarjikar] FYI there was a Solr community meetup today
and I raised this topic with [~ab] and [~hossman] responding. The general
feeling is that waitForFinalState is not needed; that this is going in the
right direction. Nobody advocated for it's continued existence. I pointed out
that "async" is useful when the client doesn't need a synchronous response...
_however_ it unfortunately litters a node into a ZK queue and eventually long
into the future gets cleaned up as that queue overflows. Very much a separate
issue would be enhancing "async" to have a sentinal value (say "true") which
would track nothing; provide no retrieval API.
What APIs does waitForFinalState seem to have some redeeming utility?
> 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: 4h 10m
> 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]
