[
https://issues.apache.org/jira/browse/SOLR-16615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656288#comment-17656288
]
Jason Gerlowski commented on SOLR-16615:
----------------------------------------
It's definitely a big change - at least as I've written it up generally in the
title/description. But there's definitely a range of complexity across
different solrconfig.xml-related components, and we can take a piecemeal
approach here. Elephants are eaten one bite at a time and all that. The
simplest ones we can handle first and could target main+branch_9x. Obviously
(for anyone that's read SOLR-16531) I'm hoping that Jersey/JAX-RS is one of
those less intertwined components; I'm working on a PoC to prove that out now.
bq. Perhaps this means, we need to make SolrCore light and instead move things
to the ConfigSet
That feels like the right general direction to me, yep.
> Colocated cores with the same configset should share resources
> --------------------------------------------------------------
>
> Key: SOLR-16615
> URL: https://issues.apache.org/jira/browse/SOLR-16615
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Jason Gerlowski
> Priority: Minor
> Labels: API, performance
>
> Currently, each core parses solrconfig.xml and instantiates its own copy of
> various plugins (v2 'Api' instances, RequestHandlers, etc.) or plugin-related
> objects (e.g. Jersey "ApplicationHandlers").
> Usually this is fine, but when many cores on a Solr node share the same
> configset, this duplication can become wasteful and have considerable impacts
> on node startup and core reload time.
> We should investigate whether some of these solrconfig.xml-driven entities
> can be shared by cores with the same configset that live in the same JVM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
