-
Notifications
You must be signed in to change notification settings - Fork 2.6k
(asyncio) PubSub does not automatically reconnect #2089
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
Does the synchronous version auto-reconnect? |
Good question. I'd guess not, because the "connect" feature is part of the |
Finally got round to do this. |
So, what should I do? Should I attempt to provide a PR (or extend #2256) to make the corresponding fix to the async version? @agronholm ? Are there any maintainers here who have an opinion on these things? @chayim ? |
The best course of action would probably be to make a new PR that adapts the tests from #2256 to async and implements that functionality on the async side. |
@kristjanvalur Agree with @agronholm, if you can provide a new PR that will be great! |
Will do. Working on getting the tests clear and indicative of the problem. |
So, I spent some time on making these unittests and having them reliable. In the process, I discovered that the issue was only present when using Researching this, I noticed how very much the async library is just a straight copy of the synchronous library. There are many inefficiencies, such as the use of |
Uh oh!
There was an error while loading. Please reload this page.
Version: 4.2.2
Platform: python 3.8 on windows
Description: Running a pub-sub task in a loop, requires me to manually call pubsub.connection.connect()
So:
I'm new to python redis, having previously used hiredis and written clients for UnrealEngine using it.
So, I was pleasantly surprised at how the client typically handles reconnections for you, in case there are disconnects.
However, this does not happen with the PubSub client.
Please note that I am using the
redis.asyncio
module here.There is a retry mechanism in PubSub._execute, which callse PubSub._disconnect_raise_connect in case of failure.
However, that function only calls
connect()
in case of aTimeoutError.
If there is a disconnect, for example, because of the connection to the server disappearing for a few seconds, or other,
the connection stays in a disconnected state.
In my tests, I killed and restarted the server and the
PubSub.connection
stayed in ais_connected==False
state, with any read operations resulting in aConnectionError("Connection closed by server.")
.Previously the loop looked somethign like:
If the connection becomes disconnected, the
listen()
will simply continually raiseConnectionError("Connection closed by server.")
.What I had to do, as a workaround, was to do something like this, for my listening loop:
(use the call_with_retry as a handy catch-all system)
I'm not sure if this is expected, or if it is an error, but from the documentation I'm reading, it seems like PubSub ought to be re-usable across disconnects, automatically reconnecting any previous subscriptions, etc.
UPDATE:
After PR #2148, the async
PubSub
class now has aconnect()
method, which can be used to remedythis. The top loop becomes:
Previously it was not possible to reconnect a
PubSub
object after a ConnectionError without issuing a "subscribe()" or "unsubscribe"The text was updated successfully, but these errors were encountered: