I am having difficulty nailing it down, but it appears that I am getting SocketException errors swallowed in calls to RedisClient.BlockingPopItemFromList that are not thrown to my app. Can’t quite say for sure, but really looks like the retry throws the exception and keeps trying until the RedisConfig retry timeout is exceeded and then throws a timeout exception.
Tried digging into the source code, but can’t find the originator of the exception. Could it be that in recent changes to the redis config that blocking calls are triggering spurious timeouts? I don’t recall having this with past versions.
Also, can you confirm that sending Timeout = null that it passes 0 to the underlying
Anyone else seeing issues with Blocking calls?
Not familiar with this. Exceptions shouldn’t be swallowed, the Automatic Retries feature does catch and attempt to retry Redis Operations but if the Retry Timeout exceeded it should throw not swallow and continue.
What Timeout are you referring to? there are many different Timeouts.
I will try to grab log file outputs tomorrow. The other timeout referred to the timeout for blocking pop commands (blpop, brpop, etc). Redis allows 0 for indefinite or # of seconds, and the RedisClient exposes it as a TimeSpan.
I wondered if perhaps because a blocking call doesn’t return until the blocking timeout expires, perhaps it conflicts or is overridden by the master send/receive timeout that in turn trigger the retry.
In this 2nd scenario, the blocking call is willing to wait indefinitely for an item to be added to mylist. After the recv timeout expires (1 second), the SocketException will be raised the the automatic retry will kick-in until the RetryTimeout is reached, at which point the RetryException will be raised to the caller.
Footnote: the RedisClient Blocking calls take a TimeSpan? as parameter; however, it will be evaluated to (int)TotalSeconds.
Thanks again to @mythz for helping to sort this out.