jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3889) SegmentMk StringCache memory leak
Date Thu, 21 Jan 2016 09:35:39 GMT

    [ https://issues.apache.org/jira/browse/OAK-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110336#comment-15110336

Thomas Mueller commented on OAK-3889:

> separate the shared key class into 2 different classes

Yes, I think that would be better, as it would avoid another developer in the future doing
the same mistake as I made...

> I could provide a patch

If you have time, that would be nice. Otherwise, I can do that (sometime next week), as I
wrote the original code (with the bug).

> SegmentMk StringCache memory leak
> ---------------------------------
>                 Key: OAK-3889
>                 URL: https://issues.apache.org/jira/browse/OAK-3889
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: segmentmk
>            Reporter: Alex Parvulescu
>         Attachments: StringCache.java.patch
> The StringCache is made of 2 components: a FastCache and a Lirs Cache and both caches
use the same key object 'StringCacheEntry' with the condition that the FastCache contains
the string value itself with the key while the Lirs Cache will only contain the _msb_, _lsb_
and _offset_.
> Sharing the same key leads to issues when a value qualifies for both caches as it results
in the string value ending up contained in the Lirs Cache, effectively blowing up the cache's
size. [0]
> On a test I ran I noticed the Lirs Cache going up to 800mb even though it was configured
at 256mb.
> [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/StringCache.java#L86

This message was sent by Atlassian JIRA

View raw message