Instead of using a redis client wrapped with the raw protocol, we now just use a simple tcp connection for handling request/response. There is one extra status check redis connection that is used to track the redis status and issue info/slave of etc commands This means * that Large responses are handled correctly * There is no conversion from one socket to another. Thus a performance boost esp for large responses. * Large number of events hooked up have been removed. There is still some cruft remaining with the read part of the protocol. Where a stream would help as well.
There was an issue in which after going down once the up notification would be ignored. So even though redis was up we'd detect that redis as still down.
The older system hardcoded the bind to 127.0.0.1 and that meant users could only connect locally, adding the ability to specify a bind_address means users can choose a specific address to bind to if there are multiple ips available or 0.0.0.0 for all, or not specify any address which means it binds to 127.0.0.1
When there are no slaves, and the reads go to slave is set, then we would throw an exception, but this fix sends the read also to active so that it works consistently.
In cases where there is a connection timeout set in the redis.conf, we do not crash. Basically it has been handled by using the retry flag on the node-redis. we are also not hooking to the end event on the connection to track the server up/down status. This is as previously handled by the ping. There may also be problems if the ping timeout is set to a higher number than the connection timeout. We recommend using a ping timeout much lesser than redis connection timeout.
Simplified the connection pool handling when servers go up/down Support modes in config file to use reads goes to slavs or only to the server. Removed redundant files.