-
-
Notifications
You must be signed in to change notification settings - Fork 191
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
Handle concurrent mirror requests via a resilient queue to avoid inefficient race condition on fs files #2048
Comments
Nice the
|
That's a new one - it's not related to |
It was not new to me. That is what I tried to explain here: #2027 (comment) |
Let's try with this until I won't find more time for this: The idea behind this is to lock access to the same file via single-thread executor service, but in opposite to classic locking mechanisms, we can continue content processing (like e.g. handling file inputstream) from different threads (the caller thread). This is far from an ideal solution, because if one file is accessed by multiple requests, it starts locking all requests. To improve this and implement a valid queue, we'd need to move to CompletableFutures. In the meantime, if you'd like to give it a try, you can try to use snapshot jar/docker nightly build. |
@ivy-cst I'm done for today, and not sure if I'll be here tomorrow since I'm a bit sick since a few days, so feel free to submit a PR if you'd like to continue working on this :) |
Request details
Current implementation of FS storage is focused on mitigating side effects from concurrent put operations, but it's simply inefficient. Related issues:
FileSystemStorageProvider#putFile
hangs infinitely #2046FileAlreadyExistsException
even with Reposilite 3.5.5. #2047The text was updated successfully, but these errors were encountered: