[
https://issues.apache.org/jira/browse/OAK-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098094#comment-16098094
]
Marcel Reutegger commented on OAK-5602:
---------------------------------------
bq. what if this instance is stopped for a longer time
I don't think this is a problem. Once such a cluster node is restarted, it will
only read journal entries created after the restart. The journal is currently
used for two purposes: 1) identify documents that must be evicted from the
cache on a background read and 2) identify the rough change set between two
revisions. The latter is primarily triggered by observation when two node
states are compared and will not go back to the time when the instance was
stopped.
bq. Maybe best would be to kill (rollback) such transactions after some time
That's a first step but will not be enough. The basic problem remains: the
Journal GC may remove entries (branch commits) that are still referenced by the
merge commit. This would still be the case even if we kill long running
transactions.
> avoid missing journal entries
> -----------------------------
>
> Key: OAK-5602
> URL: https://issues.apache.org/jira/browse/OAK-5602
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.6.0
> Reporter: Stefan Egli
> Fix For: 1.8
>
>
> As a follow up of OAK-5601: that one is about a situation where
> backgroundRead falls way behind and journal GC cleans up journal entries
> before it was able to read it. We should generally look into improving this
> situation, eg by having journal GC not do the clean up as long as there are
> instances that haven't read the entry. This could perhaps be achieved by
> periodically having each instance inform the rest about what journal entries
> it has processed (or simpler: how far back it would be -find- fine for
> journal entries to be GC'ed)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
