David Smiley created SOLR-16543:
-----------------------------------
Summary: Simplify ConfigSet processing; remove parts of
DistributedCollectionConfigSetCommandRunner
Key: SOLR-16543
URL: https://issues.apache.org/jira/browse/SOLR-16543
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
SOLR-16542 calls for ConfigSet commands to internally _only_ run via
DistributedCollectionConfigSetCommandRunner and not
OverseerConfigSetMessageHandler which won't exist henceforth. Given that the
ConfigSet API is extremely simple CRUD implemented on top of ZooKeeper (which
has its own CRUD of course) simply without any exotic requirements (as found
for collection processing), the complexity in
DistributedCollectionConfigSetCommandRunner is unwarranted for ConfigSets.
Removing it will allow significant simplifications between the API surface and
the actual execution from code maintainability/readability standpoint --
removing a layer of indirection. The processing need not occur in a dedicated
executor and need not support async. Special locks are probably needless(*).
When sending multiple files as part of uploading a ConfigSet, it can be
combined into a ZK multi-op, thus appear atomically, which is an improvement in
atomicity than we have today when a configSet is being updated and a collection
is pointing at it.
RE locks: ConfigSet downloading might see a partially updated ConfigSet if
multiple API modifications come into a ConfigSet, interleaving with the
reading, but that seems too exotic to justify a lock. As it is, a collection
reading a ConfigSet does it a file at a time, thus would have the same issue
and no lock saves us from this today. Users concerned about lack of atomicity
for certain scenarios when updating a ConfigSet could simply not do that --
create new ones instead, and point collections at the new one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
