[Cache] LockRegistry::compute() does not acquire a lock and gets into a recursive loop with semaphores
#44536
Labels
Comments
|
I'm encountering the same issue with Redis after upgrade from Symfony v5.3 to Symfony v5.4 |
nicolas-grekas
added a commit
that referenced
this issue
Dec 16, 2021
…aphores when possible" (nicolas-grekas) This PR was merged into the 5.4 branch. Discussion ---------- [Cache] Revert "feature #41989 make `LockRegistry` use semaphores when possible" | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #44536 | License | MIT | Doc PR | - This reverts commit 479919d, reversing changes made to 356c953. I'd like to revert this PR because using semaphores is creating problems that don't have any easy solution. Commits ------- 6bcc3cb Revert "feature #41989 [Cache] make `LockRegistry` use semaphores when possible (nicolas-grekas)"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected
5.4
Description
Our application has
AsyncAwsBundleandLiipImagineBundleinstalled, and when there are multiple (almost concurrent) requests to theliip_imagine_filterroute, we're seeing a recursive loop inSymfony\Component\Cache\LockRegistry::compute()when the AsyncAws client is trying to fetch the credentials from its cache provider (this is in its default configuration which is using thecache.appcache pool and we have this set up to use Redis for our production and staging environments). When I run theliip:imagine:cache:resolvecommand on the system once the lock registry starts looping, we just end up with a wall of repeating log messages in the output and it never breaks out of this loop:When I monkey patch the class to not use semaphores at all, everything seems to work normally.
Our production environment uses Docker images built on top of Ubuntu 18.04 with PHP 8.0 installed from the
ondrej/phpPPA and the web interface is using PHP-FPM.How to reproduce
Unfortunately, I don't have time at the moment to break this down to a small reproducer, the steps above have been pretty reliable to trigger the problem in our environment but I imagine there's probably a simpler way to do it.
Possible Solution
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: