post_action

[drmarker]

Мы в результате всех плясок с бубном вокруг этой проблемы пришли к
выводу, что промежуточных решений нет и надо писать скрипт, который
будет хранить список сессий в memcached/whatever и периодически
верифицировать его по /proc/net/tcp. То есть, например, если
пользователь уперся в лимит, а проверка сессий в /proc/net/tcp была
больше, чем N-секунд назад - проверить еще раз.

Другой вариант - уговорить Игоря таки сделать лимиты (но не просто по
ip, понятное дело). Но это дело бесполезное :)

А любой post_action (хоть и _499) между FE и BE может теряться.
Особенно, если FE и BE разнесены и так далее.

On 10/18/06, Alexey V. Belanov <alexey.belanov at gmail.com> wrote:
> Доброго дня.
>
> Не так давно переключили одну из своих внутренних файлопомоек на работу
> с post_action для динамического ограничения скоростей. Ограничивается
> скорость на сессию и количество разрешенных сессий на пользователя.
> php-шки работают на апаче, сессии хранятся в HEAP mysql таблицах,
> memcached пока не получилось внести в существующую идеологию. В общем и
> целом все работает как задумывалось за исключением "залипания" сессий. В
> рассылке уже писали об этом, но как я понимаю ограничившись банальным
> рестартом nginx-а с очисткой активных сессий дело дальше не пошло.
>
> Ситуация же следующая: клиент отправляет запрос на старт очередной
> сессии, nginx проксирует запрос на apache, тот какое-то время думает и
> отдает ответ (время конечно можно здорово уменьшить использованием
> memcached, но это ничего не решит). В это время пользователь по своей
> инициативе (проверить просто - забить все место на диске и регетом
> стартовать закачку) уже закрыл соединение с nginx, в логах которого
> появляется 499 ошибка, но апач сессию стартовал и бекпоста по ней нет.
> Сессия залипла.
>
> Вопрос - можно ли предусмотреть бекпост в такой ситуации, для нас это
> критично, да наверно и не только для нас. Пусть например будет
> дополнительно post_action_499, в любом случае ситуация идет к тому чтобы
> сделать это самостоятельно кривым хаком исходников nginx в обработчике
> этой ошибки.
>
> --
> Alexey V. Belanov <alexey.belanov at gmail.com>
>
>
>