Redis client defaulting to using wrong port

[robert-lilleker]

Hi
I'm using client version <PackageReference Include="Microsoft.AspNetCore.SignalR.StackExchangeRedis" Version="7.0.10" />

I'm using AWS valkey redis. It requires ssl to be enable and uses port 6379, I cannot change either of these things. So I make a configuration object and try to connect to the cache.

var obj = new ConfigurationOptions()
{
     Ssl = true,
     EndPoints = { { "<<CACHE_HOST>>", 6379 } }
};
     this.redis = ConnectionMultiplexer.Connect(obj.ToString());

However I get the following error when trying to connect

StackExchange.Redis.RedisConnectionException: UnableToConnect on <<CACHE_HOST>>:6380/Subscription, Initializing/NotStarted, last: NONE, origin: BeginConnectAsync, outstanding: 0, last-read: 5s ago, last-write: 5s ago, keep-alive: 60s, state: Connecting, mgr: 10 of 10 available, last-heartbeat: never, last-mbeat: 5s ago, global: 0s ago, v: 2.6.116.40240

Why is it trying to use port 6380? I've specified 6379,

Any help greatly appreciated.

[mgravell]

Interesting. I will need to step through the code to find the cause, but yes I agree that your expectation is a reasonable one. I might have expected 6380 if you had not specified a port manually.

[mgravell]

Does it behave correctly if you pass obj to connect?

[mgravell]

I'd also be interested in what obj.ToString() returns, but I can check that tomorrow.

[robert-lilleker]

Hi @mgravell It acts the same if you pass the obj directly

[mgravell]

I've checked through the code, and the only references I can find to 6380 are:

• SetDefaultPorts, which only applies if no port was specified in the endpoint (this does not apply in your case)
• AzureOptionsProvider, where the port is tested against 6380 to infer whether to apply TLS implicitly (again, this does not apply in your case, for multiple reasons including a known azure host check and the fact that you've specified TLS explicitly)

So: I'm not currently sure what is happening, but: I'm looking. I note that Microsoft.AspNetCore.SignalR.StackExchangeRedis 7.0.10 refs SE.Redis 2.2.4, which makes comparing code quite hard - I wonder if you could explicitly add a package ref to current SE.Redis:

<PackageReference Include="StackExchange.Redis" Version="2.8.24" />

This should be drop-in compatible, and will reduce the number of variables. I also find it interesting that it is failing to connect on the subscription connection; I wonder whether or not it successfully connected the interactive connection. You could also try capturing the connect log, via the optional log parameter; the easiest way to do this would be:

this.redis = ConnectionMultiplexer.Connect(obj.ToString(), Console.Out);

---

Side note: I tested the ToString() behaviour, and it is retaining the port information, even through Clone(), so: whatever is happening: it is not a failure there.

[mgravell]

current status:

[mgravell]

unrelated, but additional thought on this being the subscription connection: I don't know whether Valkey supports RESP3 - I suspect it does; in which case on up-to-date SE.Redis you could also perhaps try:

var obj = new ConfigurationOptions()
{
    Ssl = true,
    EndPoints = { { "YOUR_CACHE_HOST", 6379 } },
    Protocol = RedisProtocol.Resp3,
};

(we currently treat RESP3 as strictly opt-in, due to observable differences in some cases)

[mgravell]

My AWS experiment seems to have been unsuccessful, in that the created cluster does not seem to be routable; I can get an IPv4 address, but I cannot establish a socket; likewise, redis-cli fails to connect with "Connection timed out". I know basically nothing about AWS networking (I didn't have an AWS account until today). I'll try asking AWS for a test endpoint!

[mgravell]

I'm still struggling to get a suitable endpoint to test against directly, so: still no repro or information. However, if you are able to use the log parameter to capture what the client claims to be doing during connect, that would be super helpful. It is hard to help without more information, ultimately.