You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Thomas Mueller (JIRA)" <ji...@apache.org> on 2017/07/21 09:08:00 UTC

[jira] [Commented] (OAK-5602) avoid missing journal entries

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

Thomas Mueller commented on OAK-5602:
-------------------------------------

> periodically having each instance inform the rest

If an instance is a cluster node, what if this instance is stopped for a longer time (a day or two). Maybe it will be started again, maybe not. I see two options, both with a risk:

* A: If we assume this instance still needs to read the info, we possibly wait forever, so never clean up.
* B: If we assume this instance doesn't need to read it because it didn't say so for a long time, then we possibly remove data that is still needed.

Maybe we should use the "pessimistic" A route, with warnings in the log file saying it didn't respond / update the lease, and description on how to _manually_ remove the instance from the list.

> transaction is very long running 

Maybe best would be to kill (rollback) such transactions after some time, that is (x and y to be defined, and y > x): 

* the session / instance that writes to the transaction stops writing and rolls back after x minutes, and
* all other other sessions / instances assume it is stopped after y minutes

Otherwise I wouldn't know how to distinguish between case (a) the process was killed, and (b) the process is still running but just slow.

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