Open leenstx opened 1 year ago
I would expect you would see roughly similar things in both examples.
The library takes a "fail fast" approach to lost connections, this is because it was initially conceived with caching use-cases in mind. So if Redis was unavailable for any reason, there will be an instant error so that calling code can choose what to do. Attempting to use a connection that has been dropped will start a reconnection attempt as a spawned task, errors are still returned whilst that is happening rather than waiting. After a short-while the connection will be re-established and everything should continue working as before.
Calling code has two main options in this case, either: a) retry with a sensible back-off until the connection is re-established; or b) treat it as a cache miss and carry on. It will depend on the nature of the calling code as to which one of those two is preferable.
The error returned from .send(...)
will explain the situation though, so it's worth logging that to check the specific error. You'll get one of these errors: https://github.com/benashford/redis-async-rs/blob/master/src/error.rs particularly the Connection(connection_reason)
variant if the connection is disconnected and it's trying to reconnect. If the reconnection attempt fails (because Redis isn't running, for example) then you'll get the IO
variant. So from that you should be able to see what was happening at that particular moment in time.
Hi, I have some questions. I initialized a global connection using the
once_cell
crate, and I used it in two ways.My test order is as follows:
One way is like this (reconnect success):
One way is like this (reconnect fail):
I roughly understand that it's probably caused by multithreading. I'm new to Rust and I'm not sure if it's due to
once_cell
orredis_async
. Can you provide some guidance? I'd also like to make some small contributions toredis_async
.