Всем хеллоу!
Во время тестирования trackinfo обнаружили баг связанный с тем что обрывается соединение с сервером. Причина, предположительно, модуль Cache::Memcached::Fast считает что во время первого соединения произошла ошибка и лочит сервер на failure_timeout секунд. Лочить или нет устанавливает свойство max_failures. Эта ошибка воспроизводится только во время работы в окружении fastcgi. Сейчас из конфига мемкешей убрали опцию
max_failures (если это значение не указано либа ставит его в 0).
К сожалению у этой библиотеки нет debug режима =(. Ещё одно замечание, если поменять базовый класс в Rutube::Memcached c Cache::Memcached::Fast на Cache::Memcached то всё отлично! WTF? Oo
Отсюда делаем предположительный вывод, что либа засекает ошибку при первом обращении по ключу (оно кстати возвращается), затем вырубает сервак и после этого не может найти ключ в остальном пуле серваков.
Воспроизвести подобное поведение в скрипте не удалось =(
use Perl or die(); гы-гы =)
Во время тестирования trackinfo обнаружили баг связанный с тем что обрывается соединение с сервером. Причина, предположительно, модуль Cache::Memcached::Fast считает что во время первого соединения произошла ошибка и лочит сервер на failure_timeout секунд. Лочить или нет устанавливает свойство max_failures. Эта ошибка воспроизводится только во время работы в окружении fastcgi. Сейчас из конфига мемкешей убрали опцию
max_failures (если это значение не указано либа ставит его в 0).
К сожалению у этой библиотеки нет debug режима =(. Ещё одно замечание, если поменять базовый класс в Rutube::Memcached c Cache::Memcached::Fast на Cache::Memcached то всё отлично! WTF? Oo
Отсюда делаем предположительный вывод, что либа засекает ошибку при первом обращении по ключу (оно кстати возвращается), затем вырубает сервак и после этого не может найти ключ в остальном пуле серваков.
Воспроизвести подобное поведение в скрипте не удалось =(
use Perl or die(); гы-гы =)
Комментариев нет:
Отправить комментарий