-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
If connection to db lost then deno process die and pup/sub not resuming. #83
Comments
Any news? |
Nicely documented! I think the next step here is for another person to reproduce this(probably not so hard), and make a suggestion on how to improve it. |
As a first step, I created a test to reproduce the issue that @devalexqt reported. If it makes sense, I can look into suggesting a fix. #92 |
ProblemI think the problem is that once connection is lost, the subscriber never resumes. SolutionsTo resolve the above problem, I think that
What about the other libraries?ioredis provides the auto-reconnect and auto-resubscribe features: new Redis({
maxRetriesPerRequest: 5,
autoResubscribe: true, // When reconnected, the subscriber will also resume.
retryStrategy: times => computeNextTimeout(times),
});
https://pkg.go.dev/github.com/go-redis/redis@v6.15.8+incompatible?tab=doc#PubSub |
@devalexqt @Terkwood @sebastienfilion I'm sorry for the delay response. |
I vote to resume all subscribers when reconnected. If others like the idea of auto-reconnect, that sounds good to me, too. |
@Terkwood that was my idea. I’ve been working on a solution for the past few days; finishing testing. I hope I can push tomorrow for you all to see. |
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers#83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: #83
At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel. Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client. Having a connection object allows to easily replace the buffers. Resolves: denodrivers/redis#83
How to handle connection (and other) DB error?
Then I kill redis db process on server (emulating of problem with connections) then this app just die...
And if use try/catch, after I restart DB on server, redis.get, pub, sub not resume connection and not working.
So how to handle pub/sub error and resume connection and working state?
The text was updated successfully, but these errors were encountered: