2013-12-13 12 views
5

Wir verwenden Service Stack RedisClient's BlockingDequeue, um einige Daten persistent zu halten, bis sie verarbeitet werden können. Der aufrufende Code sieht aus wieService Stack Redis erneut verbinden nach Redis Server Neustart

using (var client = ClientPool.GetClient()) 
      return client.As<TMessage>().Lists[_channel].BlockingDequeue(timeout); 

Wenn der Server Redis Hosting neu gestartet wird, die Anschlüsse für die BlockingDequeue Zombie gehen und nie wieder zurückkehren, bis die Client-Anwendung neu gestartet wird.

Wir haben versucht, die Timeout auf der BlockingDequeue sowie der PooledConnectionManager, aber weder geholfen, ich rate, weil das Timeout auf der Serverseite erzwungen wird.

Ist diese Art von Fehlertoleranz in Service Stack integriert und wir vermissen es?

Oder ist es etwas, was unsere Implementierung handhaben sollte? Wenn ja, gibt es empfohlene Ansätze?

Antwort

1

Wir haben das gleiche Problem in unserem ServiceStack.Redis Subskriptionscode, wir haben versucht ein paar Einstellungen, wie z. B. retrycount, retrytimeout, etc, keiner von ihnen funktioniert, später unsere Problemumgehung ist die RedisException zu fangen und das Abonnement erneut zu tun.

Verwandte Themen