[
https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658312#action_12658312
]
Hoss Man commented on SOLR-921:
-------------------------------
if i understand correctly, the goal here is to reduce the number of
Class.forName calls on the same "cname" once we've already retrieved an
instance of a class using that cname, and the patch does this by caching in a
static map from cname=>Class
two things concern me about this...
1) the first time findClass("solr.FooBarBaz", "yak", "wak") is called the
patched code could make at most three Class.forName calls ("solr.FooBarBaz",
"yak.FooBarBaz", "wak.FooBarBaz"). assume "wak.FooBarBaz" winds up being the
true class name that acutally get's loaded. the next time someone calls
findClass("solr.FooBarBaz", "yak", "wak") no calls to Class.forName are made
because "solr.FooBarBaz" is found in the cache. The problem comes up when a
call is made to findClass("solr.FooBarBaz", "xxxxx", "yyyyy") ...
"wak.FooBarBaz" is returned from the cache, even though that package wasn't
even on the list of packages hte client was interested in. if we're going to
cache these results, the full arg list needs to be the cache key
2) the cache is a static map in the SolrResourceLoader class. unless i'm
mistaken, there's only going to be a single instance of that for the entire
Solr app (SolrResourceLoader will be loaded by the main/parent loader) which
means that cache will cause Class object references to bleed over from one
SolrCore to another (ie: i have a FooBarBaz plugin in my core1 lib, and that's
different then the FooBarBaz plugin in core2 (or a differnet version).
Changing the cacche to just be an instance variable of SolrResourceLoader
should solve this ... there's only one SolrResourceLoader per core (right?)
> SolrResourceLoader must cache name vs class
> -------------------------------------------
>
> Key: SOLR-921
> URL: https://issues.apache.org/jira/browse/SOLR-921
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Attachments: SOLR-921.patch
>
>
> every class that is loaded through SolrResourceLoader does a Class.forName()
> and when if it is not found a ClassNotFoundExcepton is thrown
> Then , it looks up with the various packages and finds the right class if the
> name starts with solr. Considering the fact that we usually use this
> solr.<classname> format we pay too much of a price for this. After every
> lookup the result can be cached in a Map<String,Class> and can be shared
> across all the cores and this Map can be stored at the CoreContainer level
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
