[
https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669864#action_12669864
]
Noble Paul commented on SOLR-921:
---------------------------------
We have a usecase where we load/unload tens of 1000's (yes tens of 1000s) of
cores at runtime (and we have 10's of millions of cores spread across a farm of
servers). We have identified this in profiling that this cost is indeed
significant (among other things SOLR-919 , SOLR-920 ).
As you said using FQN may obviate most of the problems.
* But my question is , are we saying this fix is too complex and hard to
understand? Or is it the "fear of the unknown" that is holding us back?
* What are the failure cases?
* The package names of all the classes we use in solrconfig/schema is never
advertised. Though the users can figure it out, with some work , isn't it
better to just solve it once and for all if it is a correct fix.
> 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
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-921.patch, 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.
