[
https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669795#action_12669795
]
Hoss Man commented on SOLR-921:
-------------------------------
Looking at the latest patch, I now see the restriction that the cache is only
used if the packages being searched are the default list. I also see the new
addition that only stores in the cache if the classloader used is the same as
that of the SolrResourceLoader (to prevent bleed over from one core to
another).
But honestly: the whole idea of tricks like this seems overly risky to me
considering how easy it is to get into "classloader hell" with java.
Does anyone have any profiling info they can share showing that this patch
actually improves performance in any particular usecases? (without adversely
affecting it in the common use cases)
Even if the package searching behavior of SolrResourceLoader really is that
expensive, then I'd rather encourage people to stop using the solr.* aliasing
and start explicitly using FQN for classes. I can't imagine Class.findClass on
an already initialized classname is measurably slower then pulling a class
instance out of this cache.
(The short names were designed just to make the example configs easier to read,
but if people in high load environments where cores are added/removed all the
time find the package alias resolution to be prohibitively expensive on core
initialization, then just don't use that that syntactic feature)
If someone has numbers showing that the cache really is faster even when
specifying FQNs in the configs, then I'd be convinced, but otherwise ..... ugh,
... it just seems like a bad idea to go down this road.
> 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.
