Соединение Redis пропало из события закрытия

В нашей конфигурации Redis мы установили тайм-аут :7 секунд

. В узле _redis мы обрабатываем событие готовности соединения redis и завершения как

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);
}

Образец журнала

[2012-07-11 08:21:29.545] [FATAL] Production - Connection Terminated on end to 'x.x.x.9' '6399'
[2012-07-11 08:21:29.803] [INFO] Production - Connection Successfully Established to 'x.x.x.9' '6399'

Но в некоторых случаях (наиболее вероятно, что Redis закрывает соединение без уведомления клиента )мы видим, что очередь команд накапливается, и запросы занимают слишком много времени, чтобы получить ответ [до момента узел -перераспределяет клиент, способный обнаруживать событие закрытия]. Во всех таких случаях обратный вызов команды возвращается с этой ошибкой Redis connection gone from close event. даже после стольких ожиданий. Похоже, что это не проблема из-за тайм-аута, поскольку обычное конечное событие не было запущено.

Проблема похожа на эту-http://code.google.com/p/redis/issues/detail?id=368

Это известная вещь, происходящая в Redis?

Есть ли способ указать, что выполнение команды [отправка и получение ответа] не должно превышать пороговое значение и в этом случае отвечать с ошибкой вместо того, чтобы заставлять клиента зависать?

Или есть другой способ вызвать событие закрытия в таких случаях, как тайм-аут сокета _?

Или мы должны проверить что-то со стороны нашего Redis? Мы проверили наш журнал Redis на уровне debugи не нашли ничего полезного, связанного с этой проблемой

. Когда мы запускаем узел -redis в режиме отладки, мы ясно видим, как клиент останавливается, а запросы накапливаются в очереди команд. Мы записали почему и длину очереди внутри сброса _на _ошибку . Мы сохранили оффлайн _очередь отключенной.

Образец протокола

Redis connection is gone from close event. offline queue 0 command queue 8

Время ответа на неудачный запрос :30388 мс [это зависит от времени ожидания в очереди команд.У первого парня в очереди максимальное время отклика, а у тех, кто следует за ним, меньше]

Обычное время отклика :1 мс

PS :Мы также зарегистрировали проблему в узле _redis