Надо решать вопросы нестабильной работы прокси или вообще отказываться от него. Балансировщик по ключам можно сделать и на уровне приложения, это будет лучше, чем писать такой код под прокси.
Скажите, а зачем
1) вызывать метод 5 раз в надежде «вдруг заработает»? Почему нельзя обеспечить стабильную работу редиса?
2) Функцию handle_exception() должен выполнять глобальный обработчик исключений в приложении, а не класс-обертка интерфейса
3) Из-за пункта 2 вы польностью лишаетесь возможности обрабатывать ожидаемые исключения при вызове функции
Софт, что использовал школник в процессе — утилита администрирования (наравне с Радмином), касперский ее палит или не палит в зависимости от настроек (Settings->Threads and Exclusion Rules->Detection of the following threat types is enabled)
И вот главная проблема в том, что при обновлении сессии меняется session_id и текущая сессия у пользователя сессия прерывается, стартует новая.
Все правильно. Сделано это как дополнительная защита от перехвата сессии. Пользователь продожает работать в системе, но перехваченная сессия уже неактуальна. Проблема — при одноверменном открытии нескольких вкладок может получиться ситаация что запрос пойдет уже по несуществующему session_id (не везде успеет обновиться). И решение тут должно быть другое — не отключать этот механизм, а хранить оба идентификатора сессий (текущий и предыдущий), пускать пользователя тоже по обоим. Время хранения предыдущего идентификатора можно уменьшить до 1 минуты.
Чую. Вариант у тех же Kaspersky для этого — смотрим программу в white list, если нет, спрашиваем у облака и предлагаем пользователю выбор действия. А там можно уже и в песочнице приложение перезапустить.
define('IN_PRODUCTION', false);
и в зависимости от ее содержимого подключать или не подключать модули, брать данные из phar архив или напрямую. Такая константа была в Kohana 2.3, но от нее отказались
К примеру, на production-сервере, мне не нужны модули, позволяющие осуществлять юнит-тесты, модули документации и т.д. Поэтому я не просто не включаю их в сборку, но и делаю отдельный /application/bootstrap.php.rename, в котором инициализирую ядро без них.
1) вызывать метод 5 раз в надежде «вдруг заработает»? Почему нельзя обеспечить стабильную работу редиса?
2) Функцию handle_exception() должен выполнять глобальный обработчик исключений в приложении, а не класс-обертка интерфейса
3) Из-за пункта 2 вы польностью лишаетесь возможности обрабатывать ожидаемые исключения при вызове функции
Все правильно. Сделано это как дополнительная защита от перехвата сессии. Пользователь продожает работать в системе, но перехваченная сессия уже неактуальна. Проблема — при одноверменном открытии нескольких вкладок может получиться ситаация что запрос пойдет уже по несуществующему session_id (не везде успеет обновиться). И решение тут должно быть другое — не отключать этот механизм, а хранить оба идентификатора сессий (текущий и предыдущий), пускать пользователя тоже по обоим. Время хранения предыдущего идентификатора можно уменьшить до 1 минуты.
похоже, проблема с днс
via dirty
innodb_file_format = Barracudaне забудьте добавить и
innodb_file_per_tabledefine('IN_PRODUCTION', false);и в зависимости от ее содержимого подключать или не подключать модули, брать данные из phar архив или напрямую. Такая константа была в Kohana 2.3, но от нее отказались
Как вариант — определить в index.php константу