Open andriikovalov opened 1 year ago
Hello, This not a bug. In your example the storage has no time to clean up old data. The point of time when data gets deleted depends on several factors, the most important ones are:
The Example below should perform better regarding the cleanup. It ensures that the Java GC and storage GC are executed and sets a very small object live time for the storage cache and increases the time budget for housekeeping.
final EmbeddedStorageManager storageManager = EmbeddedStorage
.start(Storage.ConfigurationBuilder()
.setEntityCacheEvaluator(Storage.EntityCacheEvaluator(1000, 10))
.setHousekeepingController(Storage.HousekeepingController(100, 1000_000_000))
.setStorageFileProvider(Storage.FileProvider(storagePath)).createConfiguration());
for (int i = 0; i < 50; i++) {
storageManager.setRoot(new byte[1000000]); // 1 MB
storageManager.storeRoot();
}
System.gc();
storageManager.issueFullGarbageCollection();
storageManager.issueFullFileCheck();
Okay, thank you. I thought that explicitly calling housekeeping would delete unreachable data (as mentioned in #179), but in fact it is not guaranteed, and cannot be enforced, right? Your snippet with "aggressive housekeeping" also gives me the same result (storage not shrinked).
Environment Details
Describe the bug
When I reset and store the application root, after calling
issueFullFileCheck()
the old inaccessible data seems to be still in the storage (judging from the size).To Reproduce
Expected behavior
The storage is shrinked to only contain the current root.
Additional context
I observe the same behaviour when I wrap my byte array into a root object, and repeatedly re-initialize the array and call
storeRoot()
.