[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612978#comment-16612978
]
Tomás Fernández Löbbe commented on SOLR-12767:
----------------------------------------------
I'm sorry, I think I wasn't clear enough. Right now the way this parameter
works is: The user provides a {{min_rf}} parameter, that's an integer. Solr
replies back with the "achieved" replication factor and echoes back whatever
{{min_rf}} was in the request. It doesn't do anything else with the value of
{{min_rf}} (if you discount the skip-recovery behavior I mentioned in the
description of this Jira as #2, that I believe is wrong). So, instead of
{{min_rf}} being an integer, it could just be a parameter like
{{returnAchievedReplicationFactor=true}}, and Solr would return the same value
as today. But even then, I think we should just always return the achieved
replication factor and let the user do as they please with that value. In your
question, log and retry later any time the achieved replication factor is < N
> Deprecate min_rf
> ----------------
>
> 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
> Priority: Major
>
> 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
