[
https://issues.apache.org/jira/browse/LUCENE-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006287#comment-14006287
]
Robert Muir commented on LUCENE-5696:
-------------------------------------
{quote}
If the point of the weak hash table was to manage memory, maybe Lucene should
also provide a way to have a set of CachingWrapperFilter instances with bounded
memory usage? (probably with the help of LUCENE-5695 that would make computing
RAM consumption cheaper)
{quote}
I think it sounds like a good idea, it is pretty tricky because if you are
managing a cache of these things, its a map of maps. If we want to allow it to
be bounded by memory usage, its more than just a simple policy because of that.
At least it seems difficult enough to me to do it "correctly" that we should
look into making it easier.
> Remove Weakhashmap from CachingWrapperFilter
> --------------------------------------------
>
> Key: LUCENE-5696
> URL: https://issues.apache.org/jira/browse/LUCENE-5696
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> Filters can take up a good amount of space, I think its terrible this thing
> relies entirely upon weak references.
> Actually I don't think it should use weak references at all, in my opinion,
> it should instead use a ConcurrentHashmap and coreClosedListeners to purge
> things.
> We already ensure and test since LUCENE-5553 that these listeners are always
> fired on close, even under exceptional cases, so I don't understand why we
> need weak references anywhere.
> So maybe the fix is to just move up coreClosedListener to AtomicReader? And
> maybe nuke getCoreCacheKey and getCombinedCoreAndDeletesKey.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
