lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Bialecki (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13579) Create resource management API
Date Tue, 30 Jul 2019 14:21:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message