[
https://issues.apache.org/jira/browse/LUCENE-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006451#comment-14006451
]
Uwe Schindler commented on LUCENE-5696:
---------------------------------------
bq. How will it makes things worse (are you worried about listeners piling up
in the static index case?)
The way how CWF is intended to be used: Code can use it, wrap a filter and
throw it away. This would no longer be possible. I know BlockJoin and similar
stuff use this that way.
In my opinion, we should make a FilterManager included with SearcherManager,
that has LRU stuff or better cache eviction.
The weak refs in CWF have nothing to do with memory alocation. If you revert
the whole thing (make the listener weak), it would still be the same.
The only thing that weak refs do bad is: concurrent mark phase gets heavier
(which you see as more work done by GC threads). But they don't ever prevent
stuff from beeing freed by garbage collector!
> 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]
