[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896177#comment-16896177
]
Andrzej Bialecki commented on SOLR-13579:
------------------------------------------
On the API itself:
bq. ...but the code in ResourceManagerPlugin is also independent of any
specific type of resource(s) that a pool can manage
{{ResourceManagerPlugin}} is an interface so it has no code of its own.
Subclasses implement the actual logic of what to monitor and how to control it,
so it made sense to make it a separate interface from a pool, which is
responsible for collecting and aggregating the data from components. As I
mentioned, I can easily foresee a future 1:N mapping between pool and plugins,
in order to manage different types of resource limits of a component in one
pool.
Concrete example of a component that consumes different types of resources that
we may want to manage is SolrIndexSearcher - here we have caches, merge IO,
update threads and query threads. We may want to manage all of these aspects by
registering SolrIndexSearcher in a single pool that supports these types of
mgmt plugins, instead of registering it in several pools, each managing one
aspect of the component.
bq. "loose coupling" that currently exists in the patch between the
ManagedComponent API and ResourceManagerPlugin
I agree, this is an important concern - please remember that this is just an
initial attempt to cover all bases, and I thought that using a very generic API
could protect us from the combinatoric explosion of the API between the
management framework and the different types of components. As you noted, the
unfortunate downside of this approach is the complexity of validating and
applying the modifications in the components...
We could perhaps call a type-safe and name-safe component API from a generic
management API by following a similar convention as the one used in
{{SolrPluginUtils.invokeSetters}}? Or use marker interfaces that also provide
validation / conversion. I'll look into this.
> Create resource management API
> ------------------------------
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch,
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
