BlockingPopItemFromList triggering SocketExceptions?

ServiceStack.Redis
1

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?

2

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.

3

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.

4

Yes a null TimeSpan is passed through as 0 seconds.

5

I prepared a small test app to repro what I’m seeing - can I email it directly?

6

Direct email support requires a support incident that are included with Business Licenses. If you have any incidents remaining, the support email will be displayed in the Account support page.

Otherwise if it’s a reproducible issue you can report it to: https://github.com/ServiceStack/Issues
You can add projects in a GitHub repo and link to it from the issue.

7

A conclusion for those who stumble onto this post in the future: The receive timeout value supersedes the timeout specified in BlockingPop call.

Good example : the recv timeout is greater than the blocking timeout.

RedisConfig.DefaultReceiveTimeout = -1    // none
...
RedisClient.BlockingPopItemFromList("mylist", TimeSpan.FromSeconds(1))

Bad example : the recv timeout is less than the blocking timeout.

RedisConfig.DefaultReceiveTimeout = 1000
...
RedisClient.BlockingPopItemFromList("mylist", null)

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.