[
https://issues.apache.org/jira/browse/OAK-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2192:
---------------------------------
Attachment: OAK-2192-v3.patch
attaching v3 of the draft patch. the extra bits are the compaction strategy
classes. this allows for a finer grained control over the segmentid cleanup
from the segmentidtable following a compaction run.
the cleanup strategy are as follows:
- _none_ which would sum-up what is happening now on trunk
- _all_ the aggresive approach from v2 of this patch, this clears all
segmentid refs allowing for a full GC run.
- _timestamp_ this will be a timestamp based approach, meaning clear every
segment older than a specific value of milliseconds.
I'm also trying to do something sneaky with the _ SegmentNotFoundException_ in
the SegmentIdTracker. I'm logging the delta of the segmentid creation time vs
the current millis, so that we can gain better knowledge of the optimal time
window value for the _timestamp_ based approach (loosely based on Chetan's
approach in OAK-2045).
We're advancing into the realm of OAK-2045, I'm wondering if it makes sense to
merge the 2 issues, of move this discussion there even.
The naming of these new classes is quite bland, I'm open for better
alternatives :)
> Concurrent commit during compaction results in mixed segments
> -------------------------------------------------------------
>
> Key: OAK-2192
> URL: https://issues.apache.org/jira/browse/OAK-2192
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: compaction, gc
> Attachments: OAK-2192-2.patch, OAK-2192-poc-fix.patch,
> OAK-2192-possible-test.patch, OAK-2192-v2.patch, OAK-2192-v3.patch,
> OAK-2192.patch
>
>
> Changes that are committed during a segment store compaction run will be
> compacted on top of the already compacted changes. However the compactor uses
> the wrong before state in this case. Instead of compacting against the
> compacted before state it uses the un-compacted before state. The resulting
> state will thus contain references to un-compacted state, making those not
> eligible for later clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
