jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
Date Thu, 05 Jul 2012 16:16:33 GMT

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

Jukka Zitting commented on OAK-114:

bq. If we just remember the earliest revision returned by getHeadRevision, we need just one
field and the next GC cycle can skip all revisions committed later.

Good point, though one could use the same mechanism also with the "last accessed/seen" alternative
by just keeping track of the oldest revision accessed during the past few seconds. That opens
up the possibility of the journal growing without limit if a client keeps an old revision
alive for an extended amount of time, but there are ways to deal with such cases on a higher
level (see below).

bq. If we remember all revisions accessed, we'll end up with some possibly sparse list of
revisions, and the GC cycle would need to re-link these revisions - modify parent commit,
re-calculate diff - to get a consistent view.

The MicroKernel interface doesn't require the implementation to store such information (parent
commit, diff, etc.), and I see no big reason why an implementation would want to. And since
some old revisions will in any case be thrown away by garbage collection, such information
would need to be rewritten regardless of whether the resulting revision list is sparse or

bq. I can see the advantage, but this would leave the door open for some bogus polling client
that keeps some very old revision alive, which I'd like to avoid.

Such denial-of-service problems are best handled on the application or deployment level, possibly
as an explicit admin operation. The alternative approach is just as vulnerable to similar
problems, as a bogus client could keep making small commits to fill up the journal with dummy
revisions that the garbage collector couldn't throw away until 10 minutes later. Or it could
do a copy commit like {{*"/content":"/revisionX"}} to preserve content from a specific revision
indefinitely regardless of what the garbage collector does. There simply is no good way to
control or prevent such behavior on this level.

> MicroKernel API: specify retention policy for old revisions
> -----------------------------------------------------------
>                 Key: OAK-114
>                 URL: https://issues.apache.org/jira/browse/OAK-114
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mk
>            Reporter: Stefan Guggisberg
>            Assignee: Stefan Guggisberg
>         Attachments: OAK-114.patch
> the MicroKernel API javadoc should specify the minimal guaranteed retention period for
old revisions. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message