-
Notifications
You must be signed in to change notification settings - Fork 202
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
Concurrent requests for an image that has not yet been cached #38
Comments
Interesting. I guess this is possible given that there is a delay between the image being generated and actually being saved to disk. We definitely need a second check right before saving a new image to disk. Unfortunately, that doesn't help prevent generating an image twice. Probably the simplest solution would be to simply write a blank file immediately, even before the image has been generated. Then, when the manipulated image has been generated, replace the temporary file with it. Thanks for bringing this to my attention, I'll have to patch this in an upcoming release. |
@reinink You could have the same issue writing a blank file (i.e. multiple requests trying to write the blank file at the same time). Is there any reason the second request wouldn't just do a silent overwrite (or silent fail)? There would be a very small performance hit because you're generating it twice, but this would be pretty rare. |
Yeah, maybe that's even a better and simpler option, especially given how infrequently this problem will occur. Good thinking Tim! |
+1 for failing silently. Silent overwrite would require changes to Flysystem (the assertAbsent logic in Filesystem.php). |
Fixed and tagged! |
Thanks @reinink, that was quick! 👍 |
During concurrent requests (even with concurrency as low as 2), if the image has not yet been cached, a FileExistsException gets thrown:
I discovered this race condition issue while benchmarking performance on a VM running locally using ApacheBench v2.3:
The text was updated successfully, but these errors were encountered: