[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140924#comment-15140924
]
David Smiley commented on SOLR-8349:
------------------------------------
Instead of a hand-rolled cache with separate per-key locks I suggest Guava's
cache which already does this. See:
https://code.google.com/p/guava-libraries/wiki/CachesExplained
I'll commit your patch to 6 if you use that.
bq. I'm slightly surprised that a feature that can save memory, especially for
nodes with large numbers of cores hasn't generated more interest.
I think internal plumbing issues like this capture less interest since it's
something another Solr hacker can work around. I've solved what you're solving
here before for a client but without hacking Solr. It wasn't elegant... but I
recall I put a lib on the top level classpath (not per-core) and I used a
static member to hold the cache.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
