[
https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661883#comment-16661883
]
Michael Dürig commented on OAK-7234:
------------------------------------
I implemented a proof of concept patch which fails the repository to start
should the journal be out of date:
[https://github.com/mduerig/jackrabbit-oak/commit/e495bf810b5013f07ecf0e6333ca97e29b40065d]
{noformat}
java.io.IOException: The most recent journal entry is 659 seconds behind the
last modification date of the most recent tar file. This indicates that the
journal might not be up to date with thecontent in the tar files.
{noformat}
To determine whether the journal is out of data the code looks at the time
difference between the most recent journal entry and the last modified date of
the most recent tar file. The threshold for triggering the check can be
controlled via the {{-Doak.segment.max-journal-gap}} feature flag.
> Check for outdated journal at startup
> -------------------------------------
>
> Key: OAK-7234
> URL: https://issues.apache.org/jira/browse/OAK-7234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Minor
> Labels: resilience, tooling
> Fix For: 1.10
>
>
> To prevent accidentally branching the repository when the {{journal.log}}
> became outdated (e.g. OAK-3702) we could add an additional safety feature
> which would prevent the repository from starting in such cases. There's a
> couple of concerns to address:
> * What kind of tooling / guidance do we need to provide to recover should
> such a situation be detected?
> * How do we detect the {{journal.log}} being outdated?
> * How do we prevent false positives?
> * How do we deal with situation where the {{journal.log}} modifications are
> intended (e.g. by tools, of manual interventions)?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
