storeManifest(...) in ArchiveBase calls:
If two threads execute this at similar times for different MPs, there is a possibility of a race condition, where thread1 removes the parent collection folder (workspace/collection/archive) in deleteFromCollection while thread2 is running putInCollection.
This has been seen in our production 3.x system and leads to a FileNotFoundException:
As there's no real need to remove the collection folder, we should leave it around to avoid the race condition.
The general issue here is that some workspace collections are static ("archive", "composer", "executor", "sox", "videoeditor", "videosegments") whereas others are dynamic, e.g. the collection name is named after a job id and the collection name is not expected to be re-used and thus can be safely removed (currently the ingest service uses collections like this).
In the case of static collections, it is always unsafe to remove the parent folder when removing an item from a collection, as some other thread could be attempting to write to that collection.
This goes for workspace and WFR methods.
That commit above was added after v3.3. The v3.3 has an "optional" delete parent directory