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

Actual Results:
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.

Expected Results:
Retraction should perform fast

Workaround (if any):


Christian Greweling
June 15, 2016, 11:41 AM

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.

Sven Stauber
June 14, 2016, 9:32 AM

Hi Christian, could you please add a quick summary about the latest insights and then close the issue?

Christian Greweling
June 9, 2016, 10:15 AM

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.

Sven Stauber
June 3, 2016, 8:54 PM

With very high I meant constant 1Gbps per second incoming traffic, but that would imply that video files would be downloaded.

Christian Greweling
June 3, 2016, 2:08 PM

@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...

Won't Fix
Your pinned fields
Click on the next to a field label to start pinning.


Christian Greweling


Sven Stauber