[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045423#comment-15045423
]
Gus Heck commented on SOLR-8349:
--------------------------------
I'm sure folks have been busy getting stuff into 5.4, but with the RC nearly
produced, perhaps someone can review this now? It's intended for 6.x, but I'd
like feedback/review so that I have something to chew on (unless of course it's
already perfect :) ). I would definitely like someone who's comfortable with
{{CoreContainer}} and class loading in Solr to take a peek. I put the
definition for {{ContainerResourceSharing}} in Lucene package space. It needed
to be there so that the hunspell analyzer for SOLR-3443 could leverage it
without depending on Solr classes (or any other Lucene class that might load a
large file that doesn't change from core to core). This patch adds no
implementation in the Lucene world, only for {{SolrResourceLoader}}. Folks who
are using Lucene in a container other than Solr can implement for their
container or not as they desire.
The intended pattern for usage within Solr (i.e. {{SearchComponent}}
implementations) is to either navigate to {{CoreContainer}} from a core if
{{CoreAware}} or cast the ResourceLoader if only {{ResourceLoaderAware}}.
Either path leads to the same place as SolrResourceLoader merely delegates to
it's CoreContainer anyway.
At the Lucene level, code would want to test {{instanceof
ContainerResourceSharing}} and do the right thing based on the result,
retaining existing behavior to support use of Lucene outside of containers on
in containers without support. Let me know if there are better ideas here...
> Allow sharing of large in memory data structures across cores
> -------------------------------------------------------------
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Affects Versions: 5.3
> Reporter: Gus Heck
> Attachments: SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large
> dictionary or other in-memory structure. When multiple cores are loaded with
> identical configurations utilizing this large in memory structure, each core
> holds it's own copy in memory. This has been noted in the past and a specific
> case reported in SOLR-3443. This patch provides a generalized capability, and
> if accepted, this capability will then be used to fix SOLR-3443.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
