Archive operation should use filesystem copy rather than http download
Steps to reproduce
Steps to reproduce:
1. Execute a workflow which involves the archive operation
2. Examine webserver logs (if configured with frontend)
3.
Actual Results:
[10/Mar/2015:09:41:53 +0200] 137.158.158.211 "GET /files/mediapackage/4ac40237-ba94-406e-9349-8e5e2239cfd0/eb7814ab-e404-4c73-a2bd-3d5909030a5e/presenter_59fad53f_22b8_4acd_8b5e_bb1a9f2db63b.mp4 HTTP/1.1" 1050872929 "-" "Apache-HttpClient/4.2.5 (java 1.5)" 80236803 30098 200
[10/Mar/2015:09:43:15 +0200] 137.158.158.211 "GET /files/mediapackage/4ac40237-ba94-406e-9349-8e5e2239cfd0/c3fcc3c6-62dc-4bd8-acc6-72c87f1cceb0/presentation_55beb005_c657_4122_b9d5_7e229822d029.mp4 HTTP/1.1" 1099612056 "-" "Apache-HttpClient/4.2.5 (java 1.5)" 84292418 107789 200
Expected Results:
archive operation that executes on the admin node should use a filesystem copy, but instead requests the source file via http.
As noted in MH-10554, the current version of jetty is very slow at serving these files (appears to max out at around 100 Mbps which is significantly slower than the OS read speed from storage in some configurations), and the operation uses CPU unnecessarily.
Workaround (if any):
None
Activity
We have QA'd this code on the UCT 1.6.x test system and it is now also running successfully in production in our 1.6.x system.
Basil, please could you create pull requests so this code gets into MH 1.6.x and 2.0.
Thank you for testing this and confirming that the patch solves the issue. I will open a pull request agains 1.6.x and 2.0.x within the next days.
I've opened a pull request against 1.6.x (https://bitbucket.org/opencast-community/matterhorn/pull-request/507). In 2.0, the Episode Service was removed and replaced by the Archive Service.
Hi Basil, thanks. Can you confirm that the Archive Service code doesn't have the same problem?
Stephen, thanks for pointing that out. I've adopted the fix to the Archive implementation of 2.0, see pull request https://bitbucket.org/opencast-community/matterhorn/pull-request/516
