[ 
https://issues.apache.org/jira/browse/LUCENE-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006394#comment-14006394
 ] 

Uwe Schindler commented on LUCENE-5696:
---------------------------------------

bq. 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)

Weak references can never be meant to manage memory. This is a common 
misunderstanding. The use of wek references here is to remove the hard 
reference between the two objects. Indeed its a problem here.

But if you use a IndexReaderClosedListener it may make the problem worse: The 
listener has *hard* reference to the CachingWrapperFilter. Nowadays, if you 
throw away the CachingWrapper filter, the CachingWrapperFilter is free (as 
nothing has a reference anymore to the Filter). But once this one "registers" 
itsself to the IndexReader, it has a suddenly a hard reference from IndexReader 
to the filter -> oh no! Now you have a leak. You need a weak reference in one 
direction to allow the cleanup.

> 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]

Reply via email to