Menu
I understand that CommandFlags.FireAndForget is intended for situations that you don't care about the response.
Does it also guarantee delivery even though the response isn't important for the running application?
475
StackExchange.Redis is a high performance general purpose redis client for .NET languages (C#, etc.). It is the logical successor to BookSleeve , and is the client developed-by (and used-by) Stack Exchange for busy sites like Stack Overflow.
Note: Redis Pub/Sub is fire and forget that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost. Keyspace notifications are implemented by sending two distinct types of events for every operation affecting the Redis data space.
All the keys expiring in the database 0. Note: Redis Pub/Sub is fire and forget that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.
The only other time that StackExchange.Redis needs to hold work is when verifying pre-conditions for a transaction, which is why StackExchange.Redis encapsulates such conditions into internally managed Condition instances. Read more about transactions here. If you feel you want “blocking pops”, then I strongly suggest you consider pub/sub instead:
Actually, the Redis protocol does not really support "fire and forget" operations. Except for pub/sub traffic, all Redis commands are matched with a reply, and there is no way to tell the Redis server to omit the reply.
Now some clients (like StackExchange.Redis) simulates a "fire and forget" mode through an asynchronous implementation of the protocol. Actually, the "fire and forget" mode in StackExchange.Redis is very similar to the "asynchronous" mode, except the replies are simply discarded when they are received.
Is it reliable? Well, it guarantees the delivery as far as TCP/IP guarantees the delivery. The network will try hard to transmit the packets (eventually the packets will be transmitted again if some of them are lost), but this is all handled by TCP.
Now if the server is down, or decide to close the connection, the client will only be aware when it tries to read from the socket. StackExchange.Redis may happily continue to send commands on a dead connection for a while. If you have a middletier (such as Twemproxy), the situation can be even worse.
In other words, "fire and forget" traffic will generally be sent to the server, and no message will be lost on the network, but if you have server or connection issues, some traffic can be lost before the client has a chance to notice it. I would call this a best effort behavior.
168
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
