[MGNLTOOLS-43] implement DataStore garbage collection Created: 09/Mar/11  Updated: 03/Jun/11  Resolved: 03/Jun/11

Status: Closed
Project: Repository Tools
Component/s: None
Affects Version/s: 1.1.2
Fix Version/s: 1.1.3

Type: Improvement Priority: Critical
Reporter: Martin Melcher Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Could it be that the garbage collection for jackrabbit's DataStore is not called yet?

Uploaded large files to the DMS, deleted them afterwards. Directory repositories/magnolia/repository/datastore/ has grown by size of uploads. Space is not freed, not even after shutdown/restart of Magnolia.

See: http://wiki.apache.org/jackrabbit/DataStore#Data_Store_Garbage_Collection



 Comments   
Comment by Magnolia International [ 09/Mar/11 ]

That is indeed the case.
Could be implemented as a scheduled job and/or on shutdown, for example.

Comment by Martin Melcher [ 06/Apr/11 ]

Is there already a release date for version 4.4.3 or any other possibility for a temporary workaround, e.g. triggering garbage collection through an external tool? We have a customer who rejects acceptance testing until this is fixed.

Comment by Martin Melcher [ 18/May/11 ]

This is no good. As I wrote, we have a customer who depends on this feature.
Is there a release date for Magnolia 4.4.5? Can we rely on this or will this issue be pushed again towards the next version?

Comment by Philipp Bärfuss [ 23/May/11 ]

Increasing the priority level of this ticket.

Comment by Jan Haderka [ 23/May/11 ]

can you please confirm that you did not activate such DMS content and that your instance is configured to not version DMS content on save?

Comment by Martin Melcher [ 24/May/11 ]

This happens on my local installation without activating to another server.
Would this make a difference? I would expect garbage collection to work in an author/public environment as well.

I'm not sure if versioning is enabled for DMS. I don't believe I changed the default settings.
/modules/dms/config/versionOnSave = false
but there is an entry
/modules/dms/commands/dms/activate/version
with
class = info.magnolia.module.dms.commands.DocumentVersionCommand

Comment by Jan Haderka [ 25/May/11 ]

Yes it would make a difference. If you have enabled versioning or if you have activated the content, there would be a version of that content created in the repository. Such a version is a complete copy of the content including all it's binaries. When you delete the content, versions are not deleted so you would still see binary files belonging to the versions in the data store.

There is actually one more case during which content is versioned. During deletion (in order to be able to restore the content), there is a version created. Once the content is wiped out, version is still kept. Can you try to disable staged deletion by removing config:/modules/dms/commands/dms/delete or at least by disabling the command itself (set enabled = false )? The content will no longer be versioned on deletion, so all associated assets should be removed once you have the garbage collection enabled.

Comment by Jan Haderka [ 03/Jun/11 ]

Rename the system property and use Boolean.getBoolean() to check its value.

Comment by Ondrej Chytil [ 03/Jun/11 ]

Re-opening for code cleanup.

Generated at Mon Feb 12 10:40:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.