[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035342#comment-18035342
]
David Smiley commented on SOLR-17712:
-
The deprecation is 9.x but substance of the change is underway. I need to
return to review the PR here so hopefully can make 10.
> 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: 3h
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035309#comment-18035309
]
Jan Høydahl commented on SOLR-17712:
[~dsmiley] This Jira has many commits, among them to 9.10, should probably be
resolved.
> 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: 3h
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032589#comment-18032589
]
ASF subversion and git services commented on SOLR-17712:
Commit c403855b40061ff89b031f73b62fc18a34a938f0 in solr's branch
refs/heads/branch_10_0 from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c403855b400 ]
SOLR-17712: Deprecating waitForFinalState parameter (#3756)
* SOLR-17712: Deprecating waitForFinalState parameter
in any SolrCloud command that accepts it.
It remains defaulted to false in 9, but will become true and likely removed.
> 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: 3h
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18029443#comment-18029443
]
Ilan Ginzburg commented on SOLR-17712:
--
[~dsmiley] my bad. What I said does not apply to collection creation where
indeed all replicas are created at the same time (both in the cluster state and
then the cores as you described above).
{{WAIT_FOR_FINAL_STATE}} seems to be ignored altogether for collection creation.
Actually [~psalagnac] mentioned to me the inefficiency of collection
{*}delete{*}, not collection creation. I mixed things up. :(
> 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: 1h 40m
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030494#comment-18030494
]
ASF subversion and git services commented on SOLR-17712:
Commit 6eb910a0f607a83aba9c92187145b58bc500521c in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=6eb910a0f60 ]
SOLR-17712: Deprecating waitForFinalState parameter (#3756)
* SOLR-17712: Deprecating waitForFinalState parameter
in any SolrCloud command that accepts it.
It remains defaulted to false in 9, but will become true and likely removed.
> 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: 2h 50m
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030498#comment-18030498
]
ASF subversion and git services commented on SOLR-17712:
Commit 65595e4eefd628dbbae65d1bfaa42c9dc0a6cdc8 in solr's branch
refs/heads/branch_9x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=65595e4eefd ]
SOLR-17712: Deprecating waitForFinalState parameter (#3756)
in any SolrCloud command that accepts it.
It remains defaulted to false in 9, but will become true and likely removed.
(cherry picked from commit 6eb910a0f607a83aba9c92187145b58bc500521c)
> 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: 2h 50m
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030496#comment-18030496
]
ASF subversion and git services commented on SOLR-17712:
Commit a4377386021c683a94aff80674b3ff212e45edf5 in solr's branch
refs/heads/branch_10x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a4377386021 ]
SOLR-17712: Deprecating waitForFinalState parameter (#3756)
* SOLR-17712: Deprecating waitForFinalState parameter
in any SolrCloud command that accepts it.
It remains defaulted to false in 9, but will become true and likely removed.
> 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: 2h 50m
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021471#comment-18021471
]
David Smiley commented on SOLR-17712:
-
[~aumarjikar] [~pancaroglu] , limited time left to 10 but we can at least
change the default and deprecate the setting. That should be straight-forward.
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17974020#comment-17974020
]
Ege Pancaroğlu commented on SOLR-17712:
---
Hi, is this issue still open for development?
If so, I would like to investigate and work on it.
Let me know if anyone is already working on this or if there are any
constraints.
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943665#comment-17943665
]
Abhishek Umarjikar commented on SOLR-17712:
---
[~dsmiley] So we are in favour to remove the logic and making defaults to wait.
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943577#comment-17943577
]
David Smiley commented on SOLR-17712:
-
Thanks so much for your historical knowledge on this [~ab] ! Based on this, we
can say this is entirely obsolete and should be dropped in favor of "async". A
good chance to do in a major release (main only, Solr 10).
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943473#comment-17943473
]
Andrzej Bialecki commented on SOLR-17712:
-
This was added in SOLR-11448. Before that the behavior was equivalent to
setting it to false, which was indeed problematic in many situations because
the request would return success while the action was still ongoing. However,
the reason for keeping this default was to avoid breaking clients who tolerated
this deficiency but they would surely break when setting it to true and their
requests would suddenly start timing out.
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943436#comment-17943436
]
Abhishek Umarjikar commented on SOLR-17712:
---
Also this is common flag used for multiple actions like create collection, add
replica, move replica, etc. So making true will wait for all these action to
get complete. Making true for this flag is the need of collection creation only
or you we want to consider for all other actions?
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943433#comment-17943433
]
Abhishek Umarjikar commented on SOLR-17712:
---
[~dsmiley] Would this remove the logic to the check as well wherever we are
using this flag ? Or instead just pass as true for this flag check.
> 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
>
> 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]
[jira] [Commented] (SOLR-17712) SolrCloud: remove CommonAdminParams.waitForFinalState; default to TRUE
[
https://issues.apache.org/jira/browse/SOLR-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937139#comment-17937139
]
David Smiley commented on SOLR-17712:
-
Marking as "newdev" for someone familiar with SolrCloud. It's a good onramp
into SolrCloud internals maybe.
> 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
>
> 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]
