[
https://issues.apache.org/jira/browse/OAK-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413449#comment-15413449
]
Michael Dürig edited comment on OAK-4293 at 8/9/16 12:35 PM:
-------------------------------------------------------------
I think the simplest solution would be to call {{GCJournal.persist()}} directly
from {{FileStore#cleanup(Predicate<Integer>, String)}} instead of looping it
through {{GCMonitor.cleaned()}}. This way there is no registering needed.
OTOH, I'm not too happy with the record id in the gc journal as its semantics
seem vague to me. Maybe replace it with the record id that resulted from
compaction!?
was (Author: mduerig):
I think the simplest solution would be to call {{GCJournal.persist()}} directly
from {{FileStore#cleanup(Predicate<Integer>, String)}} instead of looping it
through {{GCMonitor.cleaned()}}. This way there is no registering needed.
OTOH, I'm not too happy with the record id in the gc journal as its semantics
seem vague to me. Or better replace it with the record id that resulted from
compaction.
> Refactor / rework compaction gain estimation
> ---------------------------------------------
>
> Key: OAK-4293
> URL: https://issues.apache.org/jira/browse/OAK-4293
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Alex Parvulescu
> Labels: gc
> Fix For: Segment Tar 0.0.10
>
> Attachments: OAK-4293-v2.patch, size-estimation.patch
>
>
> I think we have to take another look at {{CompactionGainEstimate}} and see
> whether we can up with a more efficient way to estimate the compaction gain.
> The current implementation is expensive wrt. IO, CPU and cache coherence. If
> we want to keep an estimation step we need IMO come up with a cheap way (at
> least 2 orders of magnitude cheaper than compaction). Otherwise I would
> actually propose to remove the current estimation approach entirely
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
