[
https://issues.apache.org/jira/browse/JCR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155493#comment-13155493
]
Michael Dürig commented on JCR-3151:
------------------------------------
On a second though removing the comperator field from the Key class might have
some subtle side effects. The patch might break things in the situation where
different ValueIndex instances should go into the cache for the same field and
same prefix but a for a different FieldComparator implementation: despite
different, both ValueIndex instances end up at the same cache slot.
To be on the safe side I think the comperator should thus 'somehow' stay in the
Key class. One solution might be to use a WeakReference instead the comperator
instance itself. Another (a bit hacky) solution might be to use the comepator's
hashCode instead of the comperator instance itself.
> SharedFieldCache can cause a memory leak
> ----------------------------------------
>
> Key: JCR-3151
> URL: https://issues.apache.org/jira/browse/JCR-3151
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Alex Parvulescu
> Attachments: JCR-3151.patch
>
>
> The SharedFieldCache has some problems with the way it builds the cache:
> - as key is has the IndexReader
> - as value it has a inner cache (another map) that has as a key a static
> inner class called 'Key'.
> This 'Key' holds a reference to the comparator used for in the queries ran.
> Assuming this comparator is of any type that extends from
> AbstractFieldComparator (I think all of the custom JR comparators), then it
> keeps a reference to all the InderReader instances in order to be able to
> load the values as Comparable(s).
> So the circle is complete and the SharedFieldCache entries never get GC'ed.
> One option would have been to implement a 'purge' method on the cache,
> similar to the lucene mechanism, and when an InderReader gets closed is could
> call 'purge'. But that is both ugly AND is doesn't seem to work that well :)
> A more radical option is to remove the cache completely. Each instance of
> SimpleFieldComparator (the only client of this cache) already builds an array
> of the available values, so the cache would only help other instances of the
> same type. We'll not analyze this further.
> The proposed solution (patch will follow shortly) is to remove the Comparator
> reference from the Key class.
> It looks like it has no real purpose there, just to impact the 'equals' of
> the key, which makes no sense in the first place as the lucene query does not
> use the Comparator info at all.
> If anything, using the same field and 2 different Comparators we'll get 2
> different cache entries based on the same values from the lucene index.
> Feedback is appreciated!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
