lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar (JIRA)" <>
Subject [jira] Commented: (SOLR-921) SolrResourceLoader must cache name vs class
Date Fri, 23 Jan 2009 07:04:59 GMT


Shalin Shekhar Mangar commented on SOLR-921:

Hoss, the use-case is for a server with very large number of cores with cores being loaded/unloaded
all the time.

For your concern #1 -- The code does not cache if the package list passed to the method is
different from the default list of packages (which are always loaded by the webapp classloader.
So these can be shared by all cores.

On #2 -- When you put custom classes in $solr_home/lib, they have different packages from
Solr's own packages. So one would most likely put the fully qualified class name. In that
case the caching won't happen.

The only problem right now is that if you want to override a class supplied by Solr by adding
a jar to the $solr_home/lib, it won't take precedence. This can be fixed easily before we

> SolrResourceLoader must cache name vs class
> -------------------------------------------
>                 Key: SOLR-921
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Noble Paul
>             Fix For: 1.4
>         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.

View raw message