jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-114) MicroKernel API: specify retention policy for old revisions
Date Thu, 05 Jul 2012 15:24:35 GMT

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

Dominique Pfister edited comment on OAK-114 at 7/5/12 3:24 PM:
---------------------------------------------------------------

bq. If we are keeping track of when a particular revision was last returned by getHeadRevision,
wouldn't it be simple to use the same mechanism to also keep track of when revisions are returned
from or passed to other MicroKernel methods? I don't see how that would imply any more "complex
state management" than what's already needed.

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

bq. The benefit of switching from "last returned as head revision" to "last accessed/seen"
for figuring out when a revision is still needed is that we can allow unused revisions expire
much faster. With the "last accessed/seen" pattern there'll be no problem with an expiry time
of just a few seconds, which would in most cases allow the garbage collector to be much more
aggressive than with the 10 minute time proposed here.

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.

                
      was (Author: dpfister):
    bq.{quote} If we are keeping track of when a particular revision was last returned by
getHeadRevision, wouldn't it be simple to use the same mechanism to also keep track of when
revisions are returned from or passed to other MicroKernel methods? I don't see how that would
imply any more "complex state management" than what's already needed.{quote}

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

bq.{quote} The benefit of switching from "last returned as head revision" to "last accessed/seen"
for figuring out when a revision is still needed is that we can allow unused revisions expire
much faster. With the "last accessed/seen" pattern there'll be no problem with an expiry time
of just a few seconds, which would in most cases allow the garbage collector to be much more
aggressive than with the 10 minute time proposed here.{quote}

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.

                  
> 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

        

Mime
View raw message