Test why retraction of download distribution artefacts causes high network traffic
Steps to reproduce
Steps to reproduce:
1. Start a lot of retractions on the high-capacity QA server
The retract operations perform poor. We observed a very high incoming network traffic on the admin node which suggests that retraction actually seems to download files.
Retraction should perform fast
Workaround (if any):
As I described above. Retract an Event is producing a lot of jobs. With https://opencast.jira.com/browse/MH-11649 a lot of Networktraffik was produced on the admin node.
Maybe optimizing retracting events is something for a future release; by summarizing deleting elements to one job.
Hi Christian, could you please add a quick summary about the latest insights and then close the issue?
Can't see any point in the code where Retract should download video-files if nfs share is used.....
Retracting an Event is creating a lot of jobs. After
network-traffik shown by nload is "normal".
The high network-traffik was only shown at the admin mode, not at the other nodes. Even the nfs share-VM was idle.
@sven would be nice if you can verify this.
With very high I meant constant 1Gbps per second incoming traffic, but that would imply that video files would be downloaded.
@Sven Stauber: what is meant by very high?
catalog.xml and attachemnt.xml are downloaded by the Workflow.impl before retracting.
And catalog.xml is archived afterwards.
so 3. time xml is downloaded every retraction...