[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116829#comment-18116829
]
Chris M. Hostetter commented on SOLR-17712:
-------------------------------------------
{quote}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.
{quote}
to clarify: my enthusiasm was for better docs around the "cost" of using async
if you never clear the status, and for ading sentinal value asyncId value that
clients can send for explicit "fire and forget" situations.
I don't know/remember/understand what waitForFinalState did/does to have an
opinion on removing it.
> 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]
