-
Notifications
You must be signed in to change notification settings - Fork 660
Test parallel downloads #2728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test parallel downloads #2728
Conversation
c7ff03e
to
e871189
Compare
The windows tests fail, probably already broken since #2723:
Maybe it does not work when another process is renaming the same file? |
e871189
to
5987c4b
Compare
The fix works for windows for the metadata files, but renaming the data file fails:
We know that the "data" does not exist, not sure why os.Rename() fails. |
Adding logs:
@AkihiroSuda looks like the windows lock is broken. We don't have tests for the lockutil so this is expected :-) |
Or maybe on windows the lock works only for different processes? We used the same process to simplify the test, but maybe we should test separate processes. We can create a minimal executable that run fileutils.Download(), or maybe create a hidden |
8d39947
to
a64eba6
Compare
The windows tests pass now. I will split the lockutil fix to another pr, it is much worse bug than the rare failure for parallel downloads. |
Added separate PR for lockutil: #2729. I'll rebase and squash the commit when it is merge. |
a64eba6
to
5564c67
Compare
5564c67
to
bd29c09
Compare
Add sub tests for parallel downloads with "with cache" and "caching-only mode". The test run 20 concurrent downloads with the current test http server and ensure that downloads succeeded. To make it possible to test using the same process, we include now a counter in the perProcessTempfile. The file name is now: {filename}.pid.{count} The test revealed an issue with clonefile, not seen when testing 3 parallel `limactl create`. When the data file is replaced during a clonefile syscall, it may fail with: clonefile failed: no such file or directory This smells like a darwin bug, but we can avoid this issue by using the first download result. When a download finishes, we check if data file exists, and return success if it does. We take a lock for the very short time needed to check and rename the temporary data file to the target file. The parallel tests failed on windows - it seems that os.Rename() does not work on windows if the target exist. Replacing atomicWrite with a simpler version that takes a lock and write the file fixes the issue. Tested using: % go test ./pkg/downloader -run 'TestDownloadRemote/with_cache/parallel' -count=1000 ok github.com/lima-vm/lima/pkg/downloader 116.025s % go test ./pkg/downloader -run 'TestDownloadRemote/caching-only_mode/parallel' -count=1000 ok github.com/lima-vm/lima/pkg/downloader 98.535s Signed-off-by: Nir Soffer <[email protected]>
bd29c09
to
709f513
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Add sub tests for parallel downloads with "with cache" and "caching-only
mode". The test run 20 concurrent downloads with the current test http
server and ensure that downloads succeeded.
To make it possible to test using the same process, we include now a
counter in the perProcessTempfile. The file name is now:
The test revealed an issue with clonefile, not seen when testing 3
parallel
limactl create
. When the data file is replaced during aclonefile syscall, it may fail with:
This smells like a darwin bug, but we can avoid this issue by using the
first download result. When a download finishes, we check if data file
exists, and return success if it does. We take a lock for the very
short time needed to check and rename the temporary data file to the
target file.
The parallel tests failed on windows - it seems that os.Rename() does
not work on windows if the target exist. Replacing atomicWrite with a
simpler version that takes a lock and write the file fixes the issue.
Tested using: