[jira] [Commented] (OAK-4088) CacheLIRS prevents cleanup from being effective

["Francesco Mari (JIRA)" <ji...@apache.org>]

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

Francesco Mari commented on OAK-4088:
-------------------------------------

[~tmueller], can you help me understand this issue? Is it possible that {{CacheLIRS}} maintains references to its keys or values even after the cache is invalidated? If needed, I can provide some heap dump to analyse.

> CacheLIRS prevents cleanup from being effective
> -----------------------------------------------
>
>                 Key: OAK-4088
>                 URL: https://issues.apache.org/jira/browse/OAK-4088
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, segmentmk, tarmk-standby
>            Reporter: Francesco Mari
>             Fix For: 1.6
>
>
> While performing some tests on compaction in the context of the cold standby, I spotted an issue involving {{CacheLIRS}} and the {{SegmentTracker}}.
> Cleanup on the standby store is inefficient due to many references to {{SegmentId}} instances. These references prevent the system to identify unused segments, thus making the cleanup process less effective. To minimise the amount of references to {{SegmentId}} instances, the current implementation of the cleanup process forces every cache to be invalidated, including {{CacheLIRS}}. Unluckily, even if {{CacheLIRS}} is invalidated, heap dumps show a lot of references to {{SegmentId}} instances held by {{CacheLIRS}} and its inner classes. 
> To verify my hypothesis, I tried to run the system with an implementation of the {{SegmentTracker}} that doesn't populate {{CacheLIRS}} - the cache is always empty. This greatly improved the effectiveness of compaction, to the point that the standby instance is able to cleanup almost the whole amount of unused segments.
> It should be investigated if this behaviour is caused by a bug in {{CacheLIRS}} or by an incorrect usage of {{CacheLIRS}} by the {{SegmentTracker}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)