Redis connection passed from closed event

In our redis configuration we set a timeout: 7 seconds

In node_redis, we handle the finished and final redis event as

client.on("ready", function() { logger.info("Connection Successfully Established to ", this.host, this.port); } client.on("end", function() { logger.fatal("Connection Terminated to ", this.host, this.port); } 

Log Example

[2012-07-11 08: 21: 29.545] [FATAL] Production - connection completed from end to 'xxx9' '6399'
[2012-07-11 08: 21: 29.803] [INFO] Production - connection successfully established on "xxx9" "6399"

But in some cases (most likely, redis closes the connection without notifying the client), we see that the command command queue adds up and takes too long to get a response [until the node -redis client can recognize the close event) . In all such cases, the return command returns with this error Redis connection gone from close event . even after so many expectations. This does not seem to be a problem due to the timeout since the regular end event was not triggered.

The problem seems similar to this - http://code.google.com/p/redis/issues/detail?id=368

Is this known to happen in redis?

Is there a way to indicate that the execution of the command [sending and receiving a response back] should not exceed the threshold value and respond with an error in this case instead of making a client stop?

Or is there another way to trigger event closure in cases like socket_timeout?

Or should we check something out of our redis side? We tracked our redis log at debug level and we did not find anything useful in connection with this issue.

When we run node -redis in debug mode, we can clearly see that the client is stalled with requests being dumped into the command queue. We recorded the reason and length of the queue inside the flush_on_error function. We kept offline_queuing disabled.

Log Example

The Redis connection is disconnected from the close event. offline queue 0 command queue 8

Response time of a failed request: 30388 ms [this changes depending on the wait on the command line. The first person in the queue has a maximum response time, and those that follow him less)

Normal response time: 1 ms

PS: We also contributed issue to node_redis

+4
source share
2 answers

We had a problem communicating with Redis. It looks like it will close the connection without informing the client. We noticed that this was a timeout problem on the server. This is the solution we are using, and since July we have not had a problem.

 var RETRY_EVERY = 1000 * 60 * 3; var startTimer = function(){ console.log('Begin the hot tub!') setInterval(function(){ try{ client.set('hot',new Date()); console.log(client.get('hot')) } catch(e){ console.log(e); } },RETRY_EVERY) }(); 

Given only one call every 3 minutes, this should not be a performance issue;)

+3
source

As for oconnecp's answer, you can't just do:

 setInterval(client.ping(), 1000 * 60 * 30); 
+2
source

All Articles