[
https://issues.apache.org/jira/browse/SOLR-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707076#comment-14707076
]
Gregory Chanan commented on SOLR-7789:
--------------------------------------
Sorry about that, I don't know what the issue is. I'll generate an svn version.
I'm not sure how much we care about this, but one issue I realized with the
patch is that it is a little aggresive about cleaning up failed CREATE
attempts. If someone concurrently is using the zkcli to add a config and using
CREATE via the API (so exclusivity checking doesn't apply), the following can
happen:
- CREATE call checks that config doesn't exist
- zkcli adds config
- CREATE tries to create and fails
- CREATE removes config as part of failure cleanup
First, we should recommend that people don't use the zkcli and the ConfigSET
API concurrently (I would argue people shouldn't use zkcli at all). But we
could be a little smarter about this case, e.g. track if the CREATE call
actually wrote anything and only clean up if something was actually written.
> 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-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]
