patsonluk commented on code in PR #2438:
URL: https://github.com/apache/solr/pull/2438#discussion_r1626345152
##########
solr/core/src/java/org/apache/solr/core/ConfigSetService.java:
##########
@@ -391,6 +402,21 @@ protected NamedList<Object>
loadConfigSetFlags(SolrResourceLoader loader) throws
*/
protected abstract SolrResourceLoader
createCoreResourceLoader(CoreDescriptor cd);
+ /**
+ * Create a SolrResourceLoader for a core with the provided configSetName.
+ *
+ * <p>By default, this will just call {@link
+ * ConfigSetService#createConfigSetService(CoreContainer)}. Child
implementation might override
+ * this to make use of the configSetName directly
+ *
+ * @param cd the core's CoreDescriptor
+ * @param configSetName an optional config set name
+ * @return a SolrResourceLoader
+ */
+ protected SolrResourceLoader createCoreResourceLoader(CoreDescriptor cd,
String configSetName) {
Review Comment:
@dsmiley thank you for the review again!
>Why? It appears it'd have no ultimate effect -- it ought to resolve the
same config for the same collection. Oh, is it the same collection for this
feature?
We want to avoid registering the synthetic collection with ZK, since it
creates various issues for our various tooling which watches the ZK for
collection changes. We have to do various checks (and it's very easy to forget
for new code) to skip the synthetic collection, which is not ideal.
>I don't love subclassing CoreDescriptor to be honest; you could just add a
generic property in the core descriptor if you needed to flag one like
"synthetic". Nonetheless overall I'm unsure why loading the ConfigSet needs to
be different here.
>Also if for some reason we felt it useful, we could change
ZkConfigSetServer.loadConfigSet such that an existing configSet name in the CD
will be used, and thus avoid resolving that.
Got it! If it's more preferable to add property to `CoreDescriptor` instead
of subclassing, we could totally do that! I thought we want to minimize changes
to existing class hence didn't touch `CoreDescriptor` 😓
Currently `ZkConfigSetService#createCoreResourceLoader` does 3 things as far
as I can tell:
1. Auto create collection in ZK if it's not already here
2. Set the configset read from ZK (off the collection from cluster state) to
CD. Ignore the pre-existing on in CD
3. Create a `ZkSolrResourceLoader` with access to the resources under the
configset in ZK
Honestly, I couldn't quite tell the purposes of 1 and 2 (probably not the
use cases I'm aware of, I am sure you will be more knowledgeable!) . For
synthetic core, we want to avoid both since the for 1., we do not want to
register the synthetic collection to ZK and for 2., since the collection is not
in ZK it would fail loading such collection from cluster stateu.
We do want 3 tho as the synthetic core is there to serve resources from the
ZK configset.
Please let me know if it all makes sense? If so, I will proceed to add
property to `CoreDescriptor` 😊
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
