[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159601#comment-15159601
]
Gus Heck commented on SOLR-8349:
--------------------------------
Sure I could, but other folks who try to use this after us will likely stumble
into that pitfall. I've played around with it and simplified BlobContent, moved
the PluginBag specific stuff to PluginBag and provided some javadoc and a user
friendly method on SolrCore which will ensure that a close hook is also
created. It seems all my goals except #3 are satisfied and we've exceeded
expectations for #2 making it possible to reliably update the content on the
fly with no danger of memory leaks (yay). I definitely like this approach
better. Attaching patch #4. The patch contains a class named
org.apache.solr.handler.component.XXCustomComponent demonstrating usage
(redacted and cleansed version of what I'm using for a client's server, adapted
to this patch) This class obviously should not be included in the commit.
> 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
> Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
