Steps to reproduce:
1. Execute a workflow which involves the archive operation
2. Examine webserver logs (if configured with frontend)
[10/Mar/2015:09:41:53 +0200] 18.104.22.168 "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] 22.214.171.124 "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
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):
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.
Hi Basil, thanks. Can you confirm that the Archive Service code doesn't have the same problem?