jackrabbit-users mailing list archives

On 26 Jun 2014, at 04:21, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-06-20 17:34, Rakesh Vidyadharan wrote:
>> Hello all,
>>
>> We are using JackRabbit 2.4.3 through Magnolia CMS. Our users had used the documents
workspace provided by Magnolia to upload large media files (movies, audio), some of which
are over 100mb. We migrated all that content away from Magnolia/JackRabbit into a regular
Apache webserver, and I set up a DataStore Garbage Collector task to remove the underlying
files that had been make unreachable by deleting the nodes.
>>
>> It turns out that the documents workspace in Magnolia uses versioning, so after the
GC run, I did not see much of a difference in the repository disk usage. I followed the steps
outlined in http://stackoverflow.com/questions/3292719/how-do-you-restore-a-versioned-node-in-a-jackrabbit-2-1-repository
to iterate over all the version history for the workspace, and found the versions that were
saved for the nodes that we had deleted. I assume it is the version history that prevents
the GC from removing the underlying files.
>>
>> Unlike the code in that post, iterating the version history nodes does not return
instances of javax.jcr.version.Version, but just regular javax.jcr.Node with primary node
type nt:version. I adapted my code accordingly to see the versions that are stored. The
question is how do I go about removing these versions from the workspace (we absolutely do
not need those versions)? The JCR API does not seem to give me any way to even restore these
nodes if I wanted to, since the API seems to require the original node, from which I can then
iterate over the saved versions and remove if needed. In our case the original nodes have
been removed, so there is no starting point to use to iterate over the version history.
>>
>> For now, I have hacked a solution where, I look up the file name for the jcr:data,
and then using the directory structure JackRabbit uses, delete the underlying files, so I
have reclaimed the disk space. This is obviously non-ideal, and I would like to find out
the proper way to go about removing old versions we do not need and reclaiming the disk space.
>
> The version histories are regular nodes. Why don't you use the JCR API to delete them?
>
> Best regards, Julian
>
Hi Julian,
Aren’t all nodes under “jcr:system” protected by default? I tried to delete the version
node as you suggested and got an exception:
Removing version node: /jcr:system/jcr:versionStorage/3a/5f/27/3a5f2714-03de-4b2b-8bb8-1b2bd1a6cb2b
ConstraintViolationException: Unable to perform operation. Node is protected.
Rakesh