You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 6, 2019. It is now read-only.
Is it intended that the retry mechanism is not supposed to work on the failure of the initial connection?
I am using cpp_redis with tacopie for the networking. I am trying to ensure my application gracefully handles the situation where the redis server cannot be reached.
I'm calling connect on the client with the first 3 parameters(host, port, connect callback), to connect to a localhost redis instance. After a reboot(when the server was no longer running), I noticed the seemingly ungraceful handling of a failed connection attempt.
During the initial connection attempt, tacopie fails to connect, as one would expect, with error 10061(connection refused). This exception makes its way up to the redis_connection::connect where it is caught and a redis_error is thrown. This exception is thrown from redis_connection::connect before the disconnect handler has been assigned, and even if it were assigned, it makes no attempt to invoke it, which would presumably be necessary to do in order to have it start a retry connection loop in accordance with the retry parameters passed in to the connect function.
As a user, I had the expectation that the reconnect mechanisms would function on the initial connection attempt the same as they would if the initial connection succeeded and then later disconnected.
The text was updated successfully, but these errors were encountered:
Also, just to save the user from being misled, in the situation where the user does not catch the exception around that initial connection attempt, the bottom of client::connect will still call the connect callback with ::ok, even though the connection has failed.
if (m_connect_callback) {
m_connect_callback(m_redis_server, m_redis_port, connect_state::ok);
}
Perhaps changing to this would add an extra level of notification to the user?
Is it intended that the retry mechanism is not supposed to work on the failure of the initial connection?
I am using cpp_redis with tacopie for the networking. I am trying to ensure my application gracefully handles the situation where the redis server cannot be reached.
I'm calling connect on the client with the first 3 parameters(host, port, connect callback), to connect to a localhost redis instance. After a reboot(when the server was no longer running), I noticed the seemingly ungraceful handling of a failed connection attempt.
During the initial connection attempt, tacopie fails to connect, as one would expect, with error 10061(connection refused). This exception makes its way up to the redis_connection::connect where it is caught and a redis_error is thrown. This exception is thrown from redis_connection::connect before the disconnect handler has been assigned, and even if it were assigned, it makes no attempt to invoke it, which would presumably be necessary to do in order to have it start a retry connection loop in accordance with the retry parameters passed in to the connect function.
As a user, I had the expectation that the reconnect mechanisms would function on the initial connection attempt the same as they would if the initial connection succeeded and then later disconnected.
The text was updated successfully, but these errors were encountered: