jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (Commented) (JIRA) <j...@apache.org>
Subject [jira] [Commented] (JCR-3151) SharedFieldCache can cause a memory leak
Date Tue, 22 Nov 2011 19:04:40 GMT

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

Michael Dürig commented on JCR-3151:
------------------------------------

Testing indicates that the patch indeed works: Without the patch applied, executing a query
with an order by clause in a loop will eat up memory very quickly and eventually result in
an OOME. With the patch applied, I can see memory decreasing up to a certain limit where GC
kicks in an the lower bound on free memory keeps stable. Also the jackrabbit-core test cases
run. So I'm all fine with the patch.
                
> 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

       

Mime
View raw message