Erroring Redis modules throw uncatchable errors.

[tayloa45]

We have been experiencing an issue where an error connecting to Redis crashes our A127 worker threads. This is acceptable sometimes but when a machine is being added or removed this causes a large number of errors and renders our server unusable until Redis comes back up.

The root cause of this is that the Redis NPM module emits an error event when something goes wrong outside a request with a callback — for example while flushing the cache. When an error event is emitted and nothing is listening to it, Node treats it as the unhandled exception it is, and destroys the thread. Adding a listener resolves the issue.

volos-cache-common needs to give users a way of handling internal errors, and volos-cache-redis needs to map that functionality onto this.client (which actually emits the errors).

[tayloa45]

Update: The same issue appears in volos-quota-redis, except that if a buffer size is set then it may not be possible to access the inner Redis emitter to attach a listener.

[theganyo]

This is s great catch. Thanks for reporting it! Do you happen to have a patch you would be willing to contribute?

[tayloa45]

Sorry, we needed a fix we could deploy quickly, so we used a slightly hacky one which detects Redis connections in the Volos objects and listens to them directly. (It just logs the error and continues at the moment.) An elegant fix meant probably editing four modules in the repo, and we've never managed to run the unit tests, so it wasn't really practical.