[ 
https://issues.apache.org/jira/browse/SOLR-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443414#comment-16443414
 ] 

David Smiley commented on SOLR-12233:
-------------------------------------

+1 to the PR.

I think it makes sense to define QParserPlugin.standardPlugins in a way 
consistent with built-in registries of some of Solr's other abstractions:
 * TransformerFactory: TransformerFactory.defaultFactories
 * QueryResponseWriter: SolrCore.DEFAULT_RESPONSE_WRITERS
 * ValueSourceParser: ValueSourceParser.standardValueSourceParsers

That said, some are using the name to Class:
 * SearchComponent: SearchComponent.standard_components

One important factor to consider is SolrCoreAware.  None of the built-in 
QParserPlugins, TransformerFactories, or QueryResponseWriters implement 
SolrCoreAware, and so it's safe to have a global/static Map to an actual 
_instance_ of these built-in classes instead of holding the Class.  It wouldn't 
even make sense for the built-in or perhaps any QParserPlugin or 
TransformerFactory to be SolrCoreAware since these are both factories that have 
a method that take the SolrQueryRequest which provide access to everything.  
Similarly ValueSourceParser.parse provides access, albeit indirectly, to the 
SolrCore.

 

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-12233
>                 URL: https://issues.apache.org/jira/browse/SOLR-12233
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 7.1.1
>            Reporter: Jeff Miller
>            Assignee: Erick Erickson
>            Priority: Minor
>              Labels: Performance, qparserplugin
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to