[
https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708955#comment-16708955
]
Francesco Mari commented on OAK-7234:
-------------------------------------
My biggest concern about this issue is how we frame the problem. We want to
make sure that the journal is not outdated. But outdated with respect to what?
We need a reference that conveys information about the behaviour of the system
before the failure and that would still work in the face of restarts. The
current timestamp at the time of startup is not a good reference for many
reasons.
I thought about comparing the timestamp of the last entry in the journal with
the timestamp of the most recent segment. I think it's safe to assume that the
timestamp of the last entry should never be older than the the most recent
segment. If this is the case, we have some segments that are not reachable by
one of the head states pointed by the journal because the journal points back
in time.
But what happens if we recover a journal, and the last valid journal entry is
older than the most recent segment? Or if the last operation run on the system
is a compaction that was interrupted before it had a chance to clean after
itself? The system will refuse to start up. I still don't have a clear idea of
how a solution for this problem would look like.
> 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)
