lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-921) SolrResourceLoader must cache name vs class
Date Sat, 20 Dec 2008 19:03:44 GMT

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


Mime
View raw message