You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From Redis 7.0+, unknown endpoints are supported as a MOVED target. Quote from MOVED redirection
The endpoint can be either an IP address, a hostname, or it can be empty (e.g. -MOVED 3999 :6380). An empty endpoint indicates that the server node has an unknown endpoint, and the client should send the next request to the same endpoint as the current request but with the provided port
However, the target detection code at ClusterDistributionChannelWriter sets the target to :6380 for the above example. As a result, the subsequent validations for cluster membership fail and even if these are suppressed using ClusterClientOptions.validateClusterNodeMembership(false), the RedisURIcreation for the new target fails due to an empty hostname.
Shouldn't the target detection supply a non-empty host based on the endpoint that received the MOVED response
PS: Some cluster information from my test setup using cluster-preferred-endpoint-type unknown-endpoint (Redis 7.0+)
We do not track the hostname to which a command was sent to as the actual socket address is just being held in the connection as internal information. The few places where we work with socket addresses are the SSL initializer and the reconnect mechanism that obtains the target address from an address supplier.
To make things more complicated, the default cluster connection (used for key-less commands) connects to a random node of the cluster and on reconnect, the cluster node is being switched.
For the time being, we attempt to resolve the host name from our topology by either checking for a host that maps to a particular port or use the hostname from the node that would be responsible for a particular slot while using the redirect port.
We attempt resolving a host name from the MOVED redirect using Partitions. First, we try to handle the redirect by port lookup. If we cannot find a host with such a port, then we attempt to use the hostname from the node that would serve the slot.
This isn't ideal as we do not track the logical hostname for connections. Additionally, our reconnect/address supplier mechanism does not expose the socket address for the connection.
We attempt resolving a host name from the MOVED redirect using Partitions. First, we try to handle the redirect by port lookup. If we cannot find a host with such a port, then we attempt to use the hostname from the node that would serve the slot.
This isn't ideal as we do not track the logical hostname for connections. Additionally, our reconnect/address supplier mechanism does not expose the socket address for the connection.
From Redis 7.0+, unknown endpoints are supported as a MOVED target. Quote from MOVED redirection
However, the target detection code at ClusterDistributionChannelWriter sets the
target
to:6380
for the above example. As a result, the subsequent validations for cluster membership fail and even if these are suppressed usingClusterClientOptions.validateClusterNodeMembership(false)
, theRedisURI
creation for the new target fails due to an empty hostname.Shouldn't the target detection supply a non-empty host based on the endpoint that received the MOVED response
PS: Some cluster information from my test setup using
cluster-preferred-endpoint-type unknown-endpoint
(Redis 7.0+)The text was updated successfully, but these errors were encountered: