[
https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673089#action_12673089
]
Hoss Man commented on SOLR-921:
-------------------------------
bq. 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?
My main concerns are:
1) that caching classes adds complexity to solve a performance problem that
could/should easily be avoidable by config change (using FQN instead of aliases)
2) I am in fact scared that caching classes *may* have unexpected adverse
behavior in atypical JVMs/servlet containers that we aren't familiar with ...
mucking with class loading is something that's notoriously problematic, so i'd
prefer we get involved in it only as a matter of last resort
bq. The package names of all the classes we use in solrconfig/schema is never
advertised.
First off: i don't think that really true. the example configs may never refer
to the full name, but every place we document classes on the wiki we link to
their javadcos with full names, and we do have a comment in the example
configs explaining what full packages the "solr.*" prefix is an alias for.
The aliasing feature was introduced early on to help the readability of the
configs, and initially had essentially 0 cost (because the aliasing resolution
was only done once at server startup). Documenting that people who deal with a
high rate of core creation should avoid using the aliases (on the CoreAdmin
page perhaps) and better advertising the full names of every class seems like a
much simpler, risk free, solution.
bq. So we can just cache short-name -> FQN and we are still fine.
Eh.
I'm still in favor of just documenting that people who want to create cores
quickly should use the FQNs -- especially since it keeps the code simpler --
but i'm not opposed to caching the String->String mappings if you guys really
think that's better.
> 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, 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.
