[
https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892241#comment-16892241
]
Hoss Man commented on SOLR-13579:
---------------------------------
I spent some time breifly skimming the patch, and TBH got lost very quickly.
I think it would be helpful (probably to more folks then just myself) if we
could discuss, in "story" form, some (existing or hypothetical) examples of
scenerios that could come up; how this new system would be helpful & behave in
those scenerios, and what classes/objects (either in this patch, or yet to be
written) would be responsible for each bit of action/reaction in those stories.
ie: I'm a solr cluster admin and I have some existing collections using the
(existing) default cache configurations. When/why might i want to setup some
pools? what types of steps would i take to do so? how would my configuration(s)
change? After i have some pools in place, what's an example of something that
might happen during runtime that would cause the ResourceManager to "do
something" with my pools/caches? what would that "do something" look like in
terms of method call stacks? what would the effective end result be from my
perspective as an external observer?
----
Some specific bits that confuse me as i try to wrap my head around the current
patch...
* If each named "pool" has exactly one ResourceManagerPlugin that contains the
(type specific) actual logic for managinging "the pool" (and the resources
using that pool) then why is the "ResourceManagerPool" class different from the
"ResourceManagerPlugin" class?
** as opposed to combining that logic into a single common base class?
** is there a one-to-many/many-to-one relationship between them that i'm not
understanding?
* can you elaborate on this comment with some concrete examples:
{quote}Each managed resource can be managed by multiple types of plugins and it
may appear in multiple pools (of different types). This reflects the fact that
a single component may have multiple aspects of resource management - eg. cache
mgmt, cpu, threads, etc.
{quote}
** ie: if "CacheManagerPlugin.TYPE" is one "type" of pool that a SolrCache
(implements ManagedResource) might be managed by, what would another
hypothetical "type" of plugin/pool be that SolrCache might also be a part of?
*** or if you can't think of a good example of two diff types that a SolrCache
would be managed by, any example of an concept/object in solr that might becom
a "ManagedResource" that could be managed by two differnt types of polugins as
part of 2 diff pools would be helpful
** What happens if a single ManagedResource is part of two different "pools"
with two different ResourceManagerPlugins that give conflicting/overlapping
instructions?
* regarding this comment...
{quote}Each pool also has plugin-specific parameters, most notably the limits -
eg. max total cache size, which the CacheManagerPlugin knows how to use in
order to adjust cache sizes.
{quote}
** does that imply that once SolrCache(s) are part of a "pool" they no longer
have their own max size(s) ? or is the configured max size of an individual
cache(s) still a hard upper bound on the "managed size" that might be set at
runtime as the plugins fire?
** how/where would someone specify a "preference" for ensuring that if a
"pool" is "full" that certain resources should be managed more agressively then
others – ex: imagine a cluster admin wants all collections to have SolrCaches
that are "as big as possible" given the resources of the machines, but wants to
give priority to a certain subset of the "important" collections if resources
get constrained; what/where would that be done?
----
Also, FYI: with this patch, we now have 2 "ManagedResource" classes in
solr/core that have absolutely nothing to do with each other...
{noformat}
$ find -name ManagedResource.java
./solr/core/src/java/org/apache/solr/rest/ManagedResource.java
./solr/core/src/java/org/apache/solr/managed/ManagedResource.java
{noformat}
...thats a little weird.
> Create resource management API
> ------------------------------
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
