sewenew/redis-plus-plus

[QUESTION] Difference between constructing RedisCluster with URI vs ConnectionOptions

billschereriii opened this issue · 2 comments

billschereriii commented

We are seeing a difference in behavior between RedisCluster constructed via a URI (submitted in string form) vs RedisCluster constructed via a ConnectionOptions object in which only the host and port are populated. Specifically, we are seeing many downstream operations fail with the RedisCluster created with ConnectionOptions, giving the error message "Redis IO error when executing command: Failed to get reply: Resource temporarily unavailable". We have seen the problem surface with many different calls. These calls are being made within a fraction of a second of the connection being established, and all are made from the same thread that instantiated the connection.

Environment:

  • OS: GitHub CI/CD Ubuntu 20.04 runner (Note: issue does not manifest under MacOS)
  • Compiler: GNU 8, 9, 10 and Intel
  • hiredis version: v1.2.0
  • redis-plus-plus version: v1.3.10

We would welcome suggestions for how to track down where the problem is stemming from. I've looked through the conversation in issue #923 that appears to be related, but I did not see anything immediately relevant.

sewenew commented

There's no difference between these two methods. In fact the constructor with URI string, calls the constructor with ConnectionOptions as parameter. You'd better give some example code on how you set the URI string.

Failed to get reply: Resource temporarily unavailable

This means the connection is timed out. You need to set a larger ConnectionOptions::socket_timeout.

However, as you mentioned that ConnectionOptions object in which only the host and port are populated. In this case, no socket_timeout is the set (the default behavior), and you should not get the timeout error.

The link you given has nothing to do with this problem. Because the link is on async interface, while you use RedisCluster not AsyncRedisCluster.

Regards

billschereriii commented

Thanks for the information! I went back to take a closer look at my implementation. For posterity here are the results:
With timeout set to 100ms, I was in fact timing out on connections. (This was to localhost, so that's a bit scary.) The volume of failures here masked the fact that for my Unix Domain Socket connections, I wasn't setting the protocol. Changing both settings made everything work as expected.