-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Async pubsub burns CPU by default. #3208
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
Comments
I guess at this point changing the default value would be a breaking change for many users. At the very least, can we add some big bold warnings to the documentation? |
I faced the same problem and wasted a lot of time because of this bug, but thanks to your post I was able to patch it faster. Thanks a lot! |
wait, what breaking change can we expect by changing this default value to None ? |
Using |
I see, that makes sense. |
Version: redis-py 5.0.3, redis 7.0.12
Platform: Python 3.12 on Linux
Description:
In
redis-py
's asyncio pubsubget_message()
function, thetimeout
kwarg defaults to 0, which means the function by default returns immediately if there is no message available. So if one were to blindly follow the example code, which essentially amounts to:They will find that the thread running this example code is pegged at 100% usage, constantly burning through that tight loop. To get the behaviour that a sane person would expect (yielding to the event loop until the message is available), they need to explicitly set
timeout=None
.This is a terrible default value which resulted in me spending an entire afternoon trying to figure out why my server was pinned at 100% CPU usage, even though there were zero messages going through the pubsub channel. I have since changed my code to use
timeout=None
, but I really think this should be the default, especially when using the async version of the client (I have not checked to see if the same footgun applies to the synchronous API).The text was updated successfully, but these errors were encountered: