[GitHub] [solr] gerlowskija commented on a diff in pull request #1314: SOLR-16615: Reinstate Jersey app-per-configset

["gerlowskija (via GitHub)" <gi...@apache.org>]

gerlowskija commented on code in PR #1314:
URL: https://github.com/apache/solr/pull/1314#discussion_r1089074431


##########
solr/core/src/java/org/apache/solr/core/SolrConfig.java:
##########
@@ -1162,4 +1176,19 @@ public ConfigNode get(String name) {
   public ConfigNode get(String name, Predicate<ConfigNode> test) {
     return root.get(name, test);
   }
+
+  /**
+   * Generates a String ID to represent the {@link ConfigSet}
+   *
+   * <p>Relies on the name of the ConfigSet, the name of the SolrConfig, the {@link
+   * String#hashCode()} to generate a "unique" id for the solr.xml data (including substitutions),
+   * and the version of the overlay. These 3 peices of data should combine to make a "unique"
+   * identifier for SolrConfigs, since those are ultimately all inputs to modifying the solr.xml
+   * result.
+   *
+   * @param configSetName the name of the configSet that this SolrConfig belongs to.
+   */
+  public String effectiveId(String configSetName) {
+    return configSetName + "-" + getName() + "-" + znodeVersion + "-" + rootDataHashCode;
+  }

Review Comment:
   > In general if we don't see a use case of sharing SolrConfigs between configSets, then I don't really see a need to make that a possibility. @gerlowskija can weigh in, but I don't really want to open that rats nest.
   
   I didn't have a single specific reason in mind.  It just seemed prudent from an "abundance of caution" perspective.  Maybe some bug will crop up where we'd want to eliminate AH sharing, maybe a paranoid admin running a multi-tenant service would want to ensure sharing doesn't happen, etc.
   
   That said I don't feel strongly about _where_ the configset name gets added.  I'll move it closer to the actual caching as suggested.



-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org