[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149420#comment-15149420
]
David Smiley commented on SOLR-8349:
------------------------------------
I see your point on CacheLoader needing to define its loading up-front; the
caller of get() doesn't specify. I was confused with JDK's ConcurrentHashMap
which I think in JDK 8 has a Function arg overloaded version. One way around
this is for the Key to be be some new class hypothetically named say
LoadingCacheKey that contains the real intended key (e.g. Node.java) plus a
reference to a JDK 8 Function (or Supplier or something like that) that the
CacheLoader will call. Then the CacheLoader would null out that function in
the key. Admittedly that a bit's hacky, but nonetheless puts most of the
tricky concurrency code into a dependent library where others maintain it; not
us. That's my intent with this.
I'll comment more later; gotta go right now.
> 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]
