[
https://issues.apache.org/jira/browse/SOLR-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14995639#comment-14995639
]
Shai Erera commented on SOLR-8062:
----------------------------------
I wanted to share a possible confusion on the user end, if we start throwing
exceptions.
Since Solr (and Lucene for that matter) is unable to rollback a specific update
request, I believe that's the reason why 'minRF' is used only as a hint, and
telling the user that the update request didn't achieve it. By not throwing the
exception, the user/client couldn't _think_ that the update request was
unsuccessful, and in fact, I believe that in many cases the update itself did
reach the failed replicas eventually.
If we start throwing an exception, I worry that users might think that the
update request was unsuccessful as a whole. If they care, they might re-issue
the request. But if they don't, then they might not realize that the update
*did* get through, and even reach the failed replicas eventually. This might
cause 'surprises' and inconsistency between what the user thinks is in the
index and what isn't.
I personally think that an exception is better than just a warning in the
response, but wanted to raise this potential confusion, in case others have an
opinion on it. Perhaps if we throw an explicit exception it will be easier to
note by users, i.e. {{UpdateNotFullyAppliedException}} or something like that.
It's not a total update failure, but it is some sort of failure cause we
weren't able to meet the client's requirements.
> Solr should raise an exception if minRf is specified and not achieved for an
> update request
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-8062
> URL: https://issues.apache.org/jira/browse/SOLR-8062
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Timothy Potter
>
> See discussion in SOLR-8034
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]