Debugging Data Corruption Issues
An issue that can be hard to debug is if the same
RedisClient instance is shared across multiple threads which can result in returning corrupted data. Typically, this is a result of using
IRedisClient field in a singleton instance or sharing it as a static instance. To prevent this, each Thread that uses Redis should retrieve the redis client within a using statement, e.g:
using var redis = redisManager.GetClient(); //...
Unfortunately the call-site which returns the corrupted response or runtime Exception doesn't identify where else the Redis client instance was being used. To help identify where client instances are being used you can assert that the client is only used in the Thread that resolved it from the pool with:
RedisConfig.AssertAccessOnlyOnSameThread = true;
This captures the Thread's StackTrace each time the client is resolved from the pool which as it adds a lot of overhead, should only be enabled when debugging connection issues.
If it does detect the client is being accessed from a different thread it will throw a
InvalidAccessException with the message containing the different Thread Ids and the original StackTrace where the client was resolved from the pool. You can compare this with the StackTrace of the Exception to hopefully identify where the client is being improperly used.
Avoiding Concurrent Usage issues
What to look out for in your code-base to prevent against multiple concurrent usage of a
IRedisClientredis instance client within a
- Never use a client instance after it has been disposed
- Never use (or return) a "server collection or resource" (e.g. Redis.Lists, lock) after the client has been disposed
- Never keep a Singleton or
staticinstance to a redis client (just the
- Never use the same redis client in multiple threads, i.e. have each thread resolve their own client from the factory