[
https://issues.apache.org/jira/browse/SOLR-16995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774660#comment-17774660
]
ASF subversion and git services commented on SOLR-16995:
--------------------------------------------------------
Commit fe728205872a87f982b937202210c0b72a21f26f in solr's branch
refs/heads/main from Vincent P
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=fe728205872 ]
SOLR-16995: Use leaderEligible property where it makes sense (#1981)
Co-authored-by: Vincent Primault <vprima...@salesforce.com>
> Refactor replica types to make it easier to add new ones
> --------------------------------------------------------
>
> Key: SOLR-16995
> URL: https://issues.apache.org/jira/browse/SOLR-16995
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Vincent Primault
> Priority: Minor
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Current replica types are integrated in the code in an ad-hoc manner.
> Consequently, it is not easy to modify the behaviour of an existing replica
> type or to add a new one.
> I'm working on separating compute from storage (with Ilan and others), and
> for the purpose of this project we would need to add a new replica type (or
> _maybe_ to alter the behaviour of existing ones). This is why I would like to
> propose some iterative refactoring steps to make it possible to do so with
> less boilerplate.
> First PR is around making it easier to work with replica counts, i.e., the
> number of replicas per replica type. It avoids tracking individually number
> of replicas of a given type via individual variables.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
