[
https://issues.apache.org/jira/browse/SOLR-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502014#comment-16502014
]
Jeff Miller commented on SOLR-12233:
------------------------------------
[~elyograg] I just saw your comment, interesting you brought that up. I did
disable a bunch of the implicit handlers in the json file since they were
showing up as heavy hitter during profiling also. Another issue I'm tracking
but isn't an easy fix is PluginBag loading of plugins from SolrConfig.java,
the class seems to look for anything implementing those interfaces and uses
reflection to look up and create instances of the classes. This is real heavy
work if a lot of core loads are happening.
Apparently very few customers use core loading often so this doesn't seem to be
widely benefitting and some of it ends up staying custom code on our side.
> 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: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.1.1
> Reporter: Jeff Miller
> Assignee: David Smiley
> Priority: Minor
> Attachments: SOLR-12233.patch
>
> 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
