[
https://issues.apache.org/jira/browse/OAK-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2817:
---------------------------------
Attachment: StandbyStore.java.patch
Attaching first iteration of the patch.
this basically reverses the order of the persisted segments so they are no
longer removed by the #cleanup method (segments are persisted only after all of
their references have been peristed).
this change however introduces an in-memory cache for the pending segments
(only data segments!), which might (probably will) throw an OOME once the diff
becomes too big.
This is first version for reference, next is replacing with the in-memory cache
with a persisted version to work around the OOME.
> TARMK Cold Standby cleanup removes too many binary segments
> -----------------------------------------------------------
>
> Key: OAK-2817
> URL: https://issues.apache.org/jira/browse/OAK-2817
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Affects Versions: 1.0.12, 1.1.7, 1.2.1
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 1.3.0, 1.2.3
>
> Attachments: StandbyStore.java.patch
>
>
> It looks like the standby cleanup process could remove a lot more binary
> segments than permitted because of the order in which such segments are
> persisted. the sync will first persist the data segment referencing a binary,
> then the binary segment itself, this introduces problems when it spreads over
> multiple tar files and the #cleanup method expects them to be persisted the
> other way around (this is an implementation detail of the cleanup, but it is
> implemented this way for efficiency).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
