You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2008/12/20 20:03:44 UTC

[jira] Commented: (SOLR-921) SolrResourceLoader must cache name vs class

    [ 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.