[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708011#comment-14708011
]
Shalin Shekhar Mangar commented on SOLR-7789:
---------------------------------------------
{quote}
I am trying to accomplish the following:
#1 Add another OverseerMessageHandler (OverseerConfigSetMessageHandler) to
handle ConfigSet-related operations.
#2 From the perspective of the non-overseer (i.e. the ConfigSetsHandler), it
looks like the operations are written to a separate queue from the collection
queue, i.e. getOverseerConfigSetQueue()
#3 Since the ConfigSet operations are most likely rare and fast, it made sense
to just use the existing collections queue "under the covers" and handle the
dispatch separately. The naming here breaks the illusion of #2, i.e. if I
return an OverseerCollectionQueue it's pretty obvious to the non-overseer
what's going on.
{quote}
Why should there be a separate queue for such operations? i.e. Why should
ZkController have method called getOverseerConfigSetQueue() at all? It should
just use the collection queue. Similarily why does this API need a new
ConfigSetsHandler and not use CollectionsHandler?
bq. Short term: rename OverseerCollectionQueue to something more
generic...DistributedTaskQueue? DistributedAsyncAwareQueue? There's nothing in
there that is actually collection specific (which is why it works for the
ConfigSet operations)
The only reason why it is called a OverseerCollectionQueue is to indicate that
it is the queue for OverseerCollectionProcessor.
TBH, all this refactoring of OverseerCollectionProcessor confuses me very much.
It looks like you want the APIs and tasks run in the overseer to be pluggable
but I haven't noticed you saying that anywhere. In the absence of them being
truly pluggable, the current API has become more complicated than it was
before. We do not need complex dispatch mechanisms in the collection processor.
If you think that it is wrong to perform tasks that do not involve a Collection
then it could simply be renamed to OverseerTaskProcessor and we can be done.
Btw we have had APIs such as clusterprops and request_status in the overseer
collection processor and I don't think it is confusing anyone.
> Introduce a ConfigSet management API
> ------------------------------------
>
> Key: SOLR-7789
> URL: https://issues.apache.org/jira/browse/SOLR-7789
> Project: Solr
> Issue Type: New Feature
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Attachments: SOLR-7789.patch, SOLR-7789.patch, SOLR-7789.patch,
> SOLR-7789.patch
>
>
> SOLR-5955 describes a feature to automatically create a ConfigSet, based on
> another one, from a collection API call (i.e. one step collection creation).
> Discussion there yielded SOLR-7742, Immutable ConfigSet support. To close
> the loop, we need support for a ConfigSet management API.
> The simplest ConfigSet API could have one operation:
> create a new config set, based on an existing one, possible modifying the
> ConfigSet properties. Note you need to be able to modify the ConfigSet
> properties at creation time because otherwise Immutable could not be changed.
> Another logical operation to support is ConfigSet deletion; that may be more
> complicated to implement than creation because you need to handle the case
> where a collection is already using the configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
