[ https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tomás Fernández Löbbe resolved SOLR-12767. ------------------------------------------ Resolution: Fixed Fix Version/s: 7.6 > 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 > Fix For: 7.6 > > Attachments: SOLR-12767.patch, 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