[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186936#comment-17186936
]
Ilan Ginzburg edited comment on SOLR-14613 at 8/29/20, 11:29 AM:
-----------------------------------------------------------------
How is the number of files a measure of anything? Why not count lines of code?
About half changed classes in this
[PR|https://github.com/apache/lucene-solr/pull/1684] are for passing a
{{CloudConfig}} instance down. These are independent of the replica placement
effort, config has to be available to the code consuming it.
The rest of the work doesn't try to cram as many classes as possible into a few
files. It's an option, can even put everything in one big java class with
static subclasses, but I don't see the value. If I'm the only to think this is
not an issue, some trivial and relatively logical grouping can be done (all
{{PropertyKey}} implementations in one file, all {{PropertyValue}}
implementations in one file). Most of the implementation classes can be
regrouped as there's no impact on the plugin writing experience by doing so.
Typed property keys and typed returned values allow plugin writers to know what
they have access to and how to consume the result, they even get help from the
IDE!
They don't have to guess what to cast a returned {{Object}} into or that a
{{Map<String, Object>}} contains Maps and Lists as values...
For the record, "something as simple as replica placement" in 8x was removed
because it didn't work. A removal that touched 287 files and many more classes
({{git show --pretty="" --name-only cc0c111949d5039a0c7cb67cad55c63e2f761298 |
wc -l}}).
was (Author: murblanc):
How is the number of files a measure of anything? Why not count lines of code?
About half changed classes in this
[PR|https://github.com/apache/lucene-solr/pull/1684] are for passing a
{{CloudConfig}} instance down. These are independent of the replica placement
effort, config has to be available to the code consuming it.
The rest of the work doesn't try to cram as many classes as possible into a few
files. It's an option, can even put everything in one big java class with
static subclasses, but I don't see the value. If I'm the only to think this is
not an issue, some trivial and relatively logical grouping can be done (all
{{PropertyKey}} implementations in one file, all {{PropertyValue}}
implementations in one file). Most of the implementation classes can be
regrouped as there's no impact on the plugin writing experience of doing so.
Typed property keys and typed returned values allow plugin writers to know what
they have access to and how to consume the result, they even get help from the
IDE!
They don't have to guess what to cast a returned {{Object}} into or that a
{{Map<String, Object>}} contains Maps and Lists as values...
For the record, "something as simple as replica placement" in 8x was removed
because it didn't work. A removal that touched 287 files and many more classes
({{git show --pretty="" --name-only cc0c111949d5039a0c7cb67cad55c63e2f761298 |
wc -l}}).
> Provide a clean API for pluggable replica assignment implementations
> --------------------------------------------------------------------
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Ilan Ginzburg
> Priority: Major
> Time Spent: 20h 40m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
