deleting large no ofeditions: fixed in 5.5.2 ?

I recall that deleting a large number of editions caused the server to crash in v 5.0.1. Is this issue resolved in 5.5.2 ? If so, any insight into how it was done ? Any best practice for removing large number of editions ? I have more than 1000 old editions that I would like to delete.

Just want to make sure if there are any known issues or best practices doing so.

Find more posts tagged with

Comments

Adam Stoller

Are you running 5.0.1 or 5.5.2? (you mention both, but I'm not sure which you are running).

The "fix" for pre-5.5.2 is to create a new branch based on the old branch with all the editions, and delete the old branch (and potentially rename the new branch to use the same name as the old branch).

I haven't had the need to go through deletion of editions in 5.5.2 (the performance hit for "too many editions on a branch" is no longer present in 5.5.2) - so I don't know if there is any "fix" needed.

If you are upgrading to 5.5.2 from 5.0.1 - you can select the editions you want coverted during the upgrade process, so as to not transfer undesired editions to the new server.

Hope that helps, at least a little

--fish
(Interwoven, Curriculum Development)

iwovGraduate

We are using 5.5.2 on Solaris 8. No upgrades.

Yes you are right, I have read that there is no limit on number of editions you can publish per branch. We have not hit any performance issues with several thousand editions so far.

Regardless of that fact, I would like to know if there are any issues if I try to run a script that will delete a large (more than a thousand) number of editions. This used to be an issue in 5.0.x.

Migrateduser

Pre 5.5.x (on Solaris), this was one of the biggest problems we'd run into. Specifically, we've been running 4.2.1 for a couple of years - but I think the backing store format was the same throughout 4.5 and 5.0.

We had a limited amount of space, so we wanted to delete old editions to free up more space. It turned out that the deletion of an edition was a heavy-processing process that stressed the TeamSite process and could take a lot of time to execute and 'dirtied' lots of the available memory. Additionally, if you deleted 1000 editions, you'd just batch up 1000 delete processes in the batch processing area where you couldn't remove them from the batch. This condition caused us to build another separate TS installation, move content over to it to create a new backing store and then replace the original backing store with the newly created one. A big pain.

Deleting the branch with all of the editions in it wasn't any better - the batch process would still have to go through and delete all of the editions 1 by 1.

Another approach we tried was to run an edtion maintenance script that was based on the log triggers provided by TeamSite. So, when we detected the creation of any edition, we'd kick off the script to see if any branches had too many editions and would delete the oldest one(s) if they were over their allotted amount. This still didn't cure the problem as it would queue up too many deletions in the batch processing area.

Then we changed our workflows to create fewer editions and instead kicked off a batch job nightly to determine which branches needed a publish and then perfomed the publish and added some cron jobs to nightly go and delete a couple of editions of branches known to hog space.

In 5.5.x, the backing store is way more efficient at handling its internal metadata and edition deletion is much faster, but still not magic. There is also the capability to stop long running processes via the admin gui that should help. I'm looking forward to reimplementing our edition maintenance script to help manage space. The multi-store capability should also help with managing large branches.

Infinite #s of editions sounds great, but I still don't have infinite disk space!

Edited by walib on 10/01/02 03:17 PM (server time).