Redis sessions getting hosed...accidental shared client I think?

ServiceStack.Redis
1

Using 4.0.40, I recently turned on Redis session caching instead of InMemory that we’ve been using for a while. I haven’t had any issues locally on development, but after the deploy it started getting hosed very quickly and Raygun got flooded with errors. Errors such as…

RedisResponseException: Protocol error: expected '$', got 'E', sPort: 61284

RedisResponseException: Unexpected reply: {"__type":"MyApp.Custom.CustomUserSession, MyApp","...

Type definitions should start with a '{', expecting serialized type 'CustomUserSession', got string starting with: 0

I quickly disabled it until I can figure this out. I’m wondering if it may be some sort of issue with how I’m registering it, the client is then getting re-used, and then I’m getting bombs related to the client getting shared across threads. Here’s my registration in AppHost…

container.Register<ServiceStack.Caching.ICacheClient>(new RedisClient("cache01.foo.bar", 6379, db: 1));

Now that I look at it, I’m almost certain it’s getting reused. I’m guessing I should be using the 2 lines shown in the example at https://github.com/ServiceStack/ServiceStack/wiki/Caching#redis? (not sure where I got this previous line of code :grimacing: )

2

Not sure where you got the other registration either, but this is how to register a Redis CacheClient:

container.Register<IRedisClientsManager>(c => 
    new PooledRedisClientManager("localhost:6379"));

container.Register(c => c.Resolve<IRedisClientsManager>().GetCacheClient());

You also don’t need to explicitly register the ICacheClient for Redis as if you have Redis and don’t have any ICacheClient registered, ServiceStack will automatically register this for you:

//container.Register(c => c.Resolve<IRedisClientsManager>().GetCacheClient());

So you can either remove the ICacheClient registration or use the one above.

1 Like