Remove Ping/Echo requirement (also: twemproxy)

[leewang0]

We use TwemProxy as a layer between C# and redis for load balancing between several redis instances. Unfortunately, it does not support echo or ping. When I try adding

{ "echo", null }

to the command map for my connection, the AssertAvailable call on line 798 of ConnectionMultiplexer.cs throws an error. I was wondering if it would be possible to add a toggle for whether or not to check for these commands? I know this request falls squarely into the "the community needs that weren’t internal priorities" category from Marc's blog post, but it would make the switch to StackExchange.Redis from BookSleeve easier.

Thanks again for providing such awesome libraries, BookSleeve was great as it was but the presence of synchronous calls in StackExchange.Redis made the move a no-brainer.

[mgravell]

Would it be acceptable to do a "get {random guid}" ? Basically, the only way to be sure whether you can talk to a server is: to talk to it. This includes issues with AUTH, but also things like broken sockets, which can only be reliably detected by trying to send (with a confirmation receive a nice to have).

Marc

[mgravell]

Ooh, or TIME - that could be a nice risk-free one (the trick is finding something that will never have false positives/negatives; however, it may be necessary to settle for "almost certainly have no...")

[eyalpost]

Just wondering if you really need to talk to the server to be sure it's available. What we do in a layer we developed on top of Booksleeve is that we assume it is up and only start a failover process when the first request fails. Not sure this makes any sense in this context but thought it's worth a try

[mgravell]

I found the full command set here : https://github.com/twitter/twemproxy/blob/master/notes/redis.md

But yes, yes we do very much need to talk to the server to check it is available, because SE.Redis moves all the connection management (including reconnect, fallback, and sharding, plus keep-alive, although that was in BookSleeve too) into the client library. If it has no way to reliably know if the server is available, it cannot function correctly.

[mgravell]

OK; I've made the appropriate changes. I've gone a bit further, though - I've added a new config option:

.Proxy = Proxy.Twemproxy
(or ",proxy=Twemproxy" in the configuration string)

This configures the command map internally, and does some other things to make sure it works appropriately (for example, giving appropriate messages if you try to use the pub/sub API or the server API, or use a non-zero database, or use a multi-key command without using hash-tags)

Please give the new build (1.0.221 or above) a go, and let me know if there are any problems.

[leewang0]

It worked! Thanks so much for making that new config option. Nice comment:

// I mean really, give me a CHANCE! I need *something* to check the server is available to me...

Looks like you went with EXISTS since TwemProxy doesn't support the TIME command. That's cool, but since there doesn't appear to be any parameters to it does Redis or TwemProxy in this case always return an invalid-number-of-parameters message? I guess even an error will confirm that a connection exists, as long as it's not an error that indicates the connection itself failed.

Well at any rate, I really appreciate you putting this patch in, thanks again.

[mgravell]

It doesn't issue a naked EXISTS - it does:

msg = Message.Create(0, flags, RedisCommand.EXISTS, (RedisValue)multiplexer.UniqueId);

where UniqueId is a per-multiplexer guid (the same guid we would have used for validation via ECHO). So it should succeed and return either 0 or 1, although in reality we ignore the result in this case. This is all inside the SendTracer method, as mentioned in the comment directly beneath the one you copied:

// see also: SendTracer (matching logic)

[leewang0]

That makes sense, I should have followed that call all the way down.