[
https://issues.apache.org/jira/browse/LUCENE-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006254#comment-14006254
]
Adrien Grand commented on LUCENE-5696:
--------------------------------------
+1 to a concurrent hash table and removing the weak hash map
bq. So maybe the fix is to just move up coreClosedListener to AtomicReader?
That would be nice. For example Elasticsearch currently uses a few hacks in
order to get the segment reader behind an Atomic reader in order to be able to
use the listener mechanism, this change would help get rid of them.
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)
> 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]
