[
https://issues.apache.org/jira/browse/OAK-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4088.
---------------------------------
Resolution: Not A Problem
Fix Version/s: (was: 1.6)
1.5.0
I tested the same deployment with three configurations:
- {{SegmentTracker}} with a LIRS cache using {{SegmentId}} instances as keys
directly.
- {{SegmentTracker}} with a LIRS cache using a surrogate key of {{SegmentId}}.
- {{SegmentTracker}} using another cache implementation, more specifically an
unbounded cache from Guava.
The system behaved in comparable ways. The amount of in-memory references to
{{SegmentId}} and {{Segment}} instances is comparable with every tested
configuration.
It looks like that the bulk of the problem was not related to {{CacheLIRS}} -
or to any cache in general - but was instead caused by OAK-4089. After fixing
OAK-4089, the system behaves as expected. As such, I'm resolving this issue as
not a problem.
> 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
> Assignee: Francesco Mari
> Fix For: 1.5.0
>
>
> 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)
