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

Andrzej Bialecki commented on SOLR-16507:
-----------------------------------------

bq. Do you think there's a point to SplitShardCmd using NodeStateProvider vs 
just going to the metrics API?

You're making my point for me ;) you could do that, but the SplitShardCmd would 
become very complex with a lot of non-reusable code - because you would still 
have to bake-in making HTTP requests to other nodes and parsing / extracting 
metrics values. So it's better to hide this complexity in a high-level utility 
API.

IMHO NodeStateProvider is a good abstraction, just its implementation needs to 
be cleaned up.

> Remove NodeStateProvider & Snitch
> ---------------------------------
>
>                 Key: SOLR-16507
>                 URL: https://issues.apache.org/jira/browse/SOLR-16507
>             Project: Solr
>          Issue Type: Task
>            Reporter: David Smiley
>            Priority: Major
>              Labels: newdev
>
> The NodeStateProvider is a relic relating to the old autoscaling framework 
> that was removed in Solr 9.  The only remaining usage of it is for 
> SplitShardCmd to check the disk space.  For this, it could use the metrics 
> api.
> I think we'll observe that Snitch and other classes in 
> org.apache.solr.common.cloud.rule can be removed as well, as it's related to 
> NodeStateProvider.
> Only 
> org.apache.solr.cluster.placement.impl.AttributeFetcherImpl#getMetricSnitchTag
>  and org.apache.solr.cluster.placement.impl.NodeMetricImpl refer to some 
> constants in the code to be removed.  Those constants could move out, 
> consolidated somewhere we think is appropriate.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to