Weird setex error

We’re getting a strange error logged in Redis using the ServiceStack Redis library:

ServiceStack.Redis.RedisResponseException: invalid expire time in setex, LastCommand:'SETEX urn:principalcacheitem:vlaw -2147483648 { /* json object */ }

This error occurs infrequently, but when it does, it appears to happen in bunches, and coincides with a spike in the CPU usage on the Redis server, which becomes unresponsive to requests from our web application (the web app is using the ServiceStack library, but we’re still able to connect with the redis-cli tool and get data that way, so Redis isn’t totally down).

We’re adding items using this bit of code:

client.Store(item, TimeSpan.MaxValue)

Is there some kind of overflow thing that’s happening occasionally? Total memory used by Redis was around 400 MB, well below the 8 GB that we set as the max. We’re using the Microsoft port of Redis (for now), which we’ve been having lots of issues with: https://github.com/MicrosoftArchive/redis.

Any idea what might be going on?

Thanks,
Lam

It sounds like the issue is with Microsoft’s old archived fork of redis-server which is an unsupported Windows port of Redis which the latest release notes says:

This is a technical preview of Redis on Windows 3.2. There are still known issues/bugs, in particular there is a bug that prevents the cluster fail-over functionality to work properly in certain scenarios. This release SHOULD NOT be used in production.

This is primarily a port for development where you can develop locally against a Redis instance on windows, but it is not intended for use in production and has known limitations. I’d first recommend switching to running and official distribution of Redis which is supported and maintained. If you absolutely need to run redis on Windows you can run the official distribution of Redis on WSL or in a VM.

Without being able to reproduce the issue I can only speculate, but it sounds like when your redis server gets overloaded it’s unable to properly process the redis command.

Although supplying a TimeSpan.MaxValue isn’t useful, if you don’t want the entry evicted you should call it without an expiry:

client.Store(item);