[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148797#comment-15148797
]
Gus Heck commented on SOLR-8349:
--------------------------------
Executive summary of the last overly long comment:
# Guava's cache is indeed a cool cache,
# It doesn't support arbitrary loaders in a way that is consistent with my
design,
# Either we can do one of these things (AFAICT):
## Use the working code I wrote (no guava cache)
## Change our goals, and use guava (allow cores loading the same resource to
all block each other until loading is done)
## Use guava and wrap it in additional loader management code of similar
complexity as my original code.
# Weak/soft values require someone to hold the strong reference.
New thought this morning: I could probably add methods and a list to the
SolrCore object for the purpose of giving it a reference to the resource at
load time, thus tying the life-cycle of the resource to the object we want it
to live and die with. Then weak values would probably work fine.
> 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
