[Question] What's the minimum version of Redis Server to work with StackExchange.Redis?

[okay9109]

What's the minimum version of Redis Server to work with StackExchange.Redis?

I'm asking this to check if Redis version 3.0.504 is expected to work with the library.

Thanks!

[mgravell]

Anything RESP2 or above - which includes 3.0.504 and quite a bit lower. Are you seeing any specific problems? By chance, Redis 3.0.5xx is actually particularly well-tested simply because Redis-64 (the now-abandoned Windows fork) is around there (I think that's 3.0.503).

[mgravell]

I looked it up; RESP aka RESP2 was released in Redis 1.2; so that is the earliest Redis version that I would expect to work. I have not explicitly tested Redis 1.2, and of course many features/commands will be missing at the server.

[okay9109]

Yes, I'm observing an issue when using Redis as a backplane for SignalR:

System.InvalidOperationException: ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / QUIT allowed in this context
   bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bei Microsoft.AspNet.SignalR.Messaging.ScaleoutStream.Send(Func`2 send, Object state)
   bei Microsoft.AspNet.SignalR.Infrastructure.Connection.Send(ConnectionMessage message)
   bei Microsoft.AspNet.SignalR.Transports.TransportConnectionExtensions.SendCommand(ITransportConnection connection, String connectionId, CommandType commandType)
   bei Microsoft.AspNet.SignalR.Transports.ForeverTransport.<>c__DisplayClass41_0.<ProcessReceiveRequest>b__0()
   bei Microsoft.AspNet.SignalR.Transports.ForeverTransport.<>c__DisplayClass41_0.<ProcessReceiveRequest>b__1()
   bei Microsoft.AspNet.SignalR.Transports.ForeverTransport.ProcessMessages(ITransportConnection connection, Func`1 initialize)
   .....

As expected, once it uses the connection for pub/sub, it does not handle other commands, but I'd expect the secondary connection would be used for the other commands and apparently it's trying to use the same connection.

We're currently using StackExchange.Redis version 2.7.33.

[mgravell]

OK; let's gather some info, then.

We have your client version - 2.7.33 - and your server version, 3.0.504, thanks. Can I check some additional things:

• the redis server; the version number is suspiciously similar to Redis-64; can I check: is this vanilla Redis, or is this Redis-64? or Memurai? or something else? and is this self-hosted? or a hosted service (and if so: which one)?
• the web server; which framework and SignalR version is this?
• if you are using Redis yourself at all (which might not be the case if you're just using it as a backplane), are you issuing any commands manually, i.e. via the Execute[Async] API?
• have you enabled RESP3? (you should not do this for this setup - I'm just thinking the symptom sounds suspiciously similar to RESP3 causes RedisServerException only (P|S)SUBSCRIBE / (P|S)UNSUBSCRIBE / PING / QUIT are allowed in this context #2783)
• finally: is there anything else relevant in play here? for example, are you routing your redis traffic through "envoy", "twemproxy", or any other TCP or Redis-specific proxy?

The library is indeed meant to take care of splitting commands between their correct connections; if that's not happening, something is wrong - let's see if we can figure out what!

(/cc @BrennanConroy just for SignalR visibility; probably nothing for SignalR to do here, though; edit: it looks most likely to be a "attempting RESP3 on a non-RESP3 server" config combined with a client library error in that area)

[okay9109]

Thanks for your swift response, @mgravell

the redis server; the version number is suspiciously similar to Redis-64; can I check: is this vanilla Redis, or is this Redis-64? or Memurai? or something else? and is this self-hosted? or a hosted service (and if so: which one)?

I don't have direct access to the Redis Server but I think I can ask for this info internally.

the web server; which framework and SignalR version is this?

.NET Framework 4.8

if you are using Redis yourself at all (which might not be the case if you're just using it as a backplane), are you issuing any commands manually, i.e. via the Execute[Async] API?

I use Redis myself too, but no manual command is fired, only via the library's APIs.

have you enabled RESP3? (you should not do this for this setup - I'm just thinking the symptom sounds suspiciously similar to

This is probably the cause of our issue, thanks for pointing that out! We try to enable RESP3 whenever possible, I'll test without forcing RESP3.

finally: is there anything else relevant in play here? for example, are you routing your redis traffic through "envoy", "twemproxy", or any other TCP or Redis-specific proxy?

As far as I'm aware the traffic is being handled normally.

[mgravell]

RESP3 is great when it works; however, Redis 3 absolutely does NOT support RESP3. The bug mentioned above will hopefully be addressed quickly - it is not expected to fail in this way.

[okay9109]

I did notice, as we log this info after establishing the connection:

multiplexer.GetServers().FirstOrDefault().Protocol;

That the actual protocol used for the connection was RESP2 after all, even when trying to set

configuration.Protocol = RedisProtocol.Resp3

But perhaps the attempt to use RESP3 already suffices to cause the issue.

[mgravell]

Yes, it is believed that the problem here happens during the attempt - basically, we need to defer any subscription code until fully after the handshake has completed successfully and we can see what the discovered setup is.

[okay9109]

Hello! Just an update for this issue, indeed when we stop forcing RESP3 protocol the issue stops happening. Thank you for the support and sorry for the late update! I'll close this as resolved.