Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Won't Fix
-
None
-
None
Description
Due to OAK-2045 we cannot perform efficient compaction on a running system as of now. To workaround that an alternative approach can be used
- Regular maintainence job (invoked via RevisionGC MBean) if determines that compaction would reclaim space above certain threshold then it sets a boolean flag under "compactionStatus" to true along with timestamp
- Post restart the maintainence job on detecting such a flag can trigger compaction and cleanup
Or in terms of pseudo code (by tmueller )
// this is called once a day in a background thread dailyMaintenance() { if (notSegmentNodeStore()) { return; } // this needs to be stored somewhere in the repo lastCompactStart = loadCompactStartFromRepo(); if (lastCompactStart > whenThisProcessWasStarted()) { return; } // this can take about 1 minute estimatedSpaceSaved = estimatedSpaceSavedByCompaction(); if (estimatedSpaceSaved < minimumSpaceSaved()) { return; } storeLastCompactStartInRepo(now); compact(); } static long CLASS_LOADED_TIME = System.currentTimeMillis(); whenThisProcessWasStarted() { // a simplification, but maybe good enough return CLASS_LOADED_TIME; }
Attachments
Issue Links
- relates to
-
OAK-2045 Long running JCR session prevent live cleanup in Segment FileStore
- Resolved