[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16628051#comment-16628051
]
Tomás Fernández Löbbe commented on SOLR-12767:
----------------------------------------------
The patch attached doesn't add much of a cleanup, changes are minor really.
I'll check and see if further improvements can be made without a huge refactor,
otherwise that will deserve it's own Jira. One thing I'm not sure I understand
is the reason behind {{getShardReplicationFactor(...)}}, It seems to address
the case of {{CloudSolrClient}} breaking update batches into multiple requests
(per shard), however, that response is being condensed in
{{CloudSolrClient.condenseResponse(...)}}, I'm not sure if this code was there
before or if there are edge cases that this code is supposed to handle.
In the patch, whenever the "min_rf" is explicitly set by the user, I'm
including it in the sub requests. This is only to support rolling upgrades and
can be removed in the future. If the user is not currently using "min_rf", and
they do a rolling upgrade, during the time of the upgrade they could receive a
MAX_INT as "achieved RF", but I think that's fine, since they won't be
consuming the value anyway, and it should be for a short period of time. I
don't think it's worth to add more code to handle this situation better, but
I'm open to suggestions.
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
