[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632608#comment-16632608
]
Anshum Gupta commented on SOLR-12767:
-------------------------------------
Looks good to me.
Here are a few minor (nit-pick?) suggestions:
* I know you already have an entry in the Bug Fixes and the Improvements
section, but I think this would be a good thing to add to the 'upgrading from'
section too? Just as this is a user facing param that we want to remove.
* In DistributedUpdateProcessor.java - Can you add a TODO tag there?
{code:java}
+ // Kept for rolling upgrades only. Should be removed in Solr 9{code}
> Deprecate min_rf parameter and always include the achieved rf in the response
> -----------------------------------------------------------------------------
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Tomás Fernández Löbbe
> Assignee: Tomás Fernández Löbbe
> Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch,
> SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
