use ClientPool to prevent race conditions when using pylibmc as memcached package #287
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch aims to fix concurrency issues when using the
gthread
worker class in gunicorn in combination with thepylibmc
Memcached backend by utilizing aClientPool
rather than a singleClient
. This issue was also (partially) detailed in pallets-eco/flask-caching#113.The proposed solution should work for every gunicorn worker configuration, so this patch always uses a
ClientPool
in an attempt to not further complicate the code with unnecessary branching statements. If you prefer it otherwise, I can still change that using a configuration switch.Note that this patch also requires some changes to the
flask-caching
repository, but I first want to iterate on it here before opening another PR in that repository.Checklist:
CHANGES.rst
summarizing the change and linking to the issue... versionchanged::
entries in any relevant code docs.pre-commit
hooks and fix any issues.pytest
andtox
, no tests failed.