lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
Date Thu, 13 Sep 2018 05:23:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613036#comment-16613036
] 

Erick Erickson commented on SOLR-12767:
---------------------------------------

Ah, ok. I vaguely remember being in that code at one point and it seemed kind of hacked together
so likely could use some cleaning up....

> 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
>            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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message