jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-7234) Check for outdated journal at startup
Date Wed, 05 Dec 2018 08:24:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16709730#comment-16709730
] 

Michael Dürig commented on OAK-7234:
------------------------------------

{quote}My biggest concern about this issue is how we frame the problem.
{quote}
Agreed. I think it's safe to use the timestamp of the latest journal entry on one hand. But
what to compare it against? We'd need some way to determine a timestamp from when the repository
shut down the last time. In my patch I use the timestamp of the most recent tar file. But
I'm really not sure whether this is a good heuristic. 

So far I only know of a few cases where we had to deal with an outdated journal. So any heuristic
which has a higher false positive rate than that would effectively make matters worse.

 

One other thing I could think of: run the journal recovery tool and let it recover a few minutes
worth of revisions. If non of those match the head revision in the journal then log an error
and refuse to start.

> 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)

Mime
View raw message