Re: Re[2]: платформа для REST сервисов

[Sergey Shepelev]

OMFG уважаемые господа, речь шла о таймаутах событийной машины.
Конект за 10 секунд - что-то произойдет раньше - либо конект, либо 10 секунд.
В nginx есть proxy_connect_timeout. Речь об этом была, йолки.

2009/1/8 Sergey Bondari <bondari at 1stomni.com>:
> Hello Sergey,
>
> Мне тоже кажется что вы не понимаете концепции асинхронных событийных
> приложений. Таймаут там не нужен по такой простой причине что пока не пришло
> событие, делать-то нечего. А чтобы никого не "теребить" и существуют
> механизмы которые отслеживают события на N ресурсах одновременно.
>
> Когда вы попробуете написать событийную машину в которую вы
> попытаетесь вставить таймаауты и синхронные вызовы вы поймете что это
> не тривиально. Событийная машина не имеет права застывать на каких-то
> синхронных вызовах с таймаутом, иначе она теряет свой смысл. Все
> должно выполняться асинхронно. Асинхронно помещаете в пул запрос,
> когда принимающая сторона готова к приему, посылаете запрос, когда
> ответ готов, получаете событие и принимаете ответ. Обрабатываете
> ответ, скажем, вашим колбэком, т.е. функцией которая висит в пуле
> вместе с запросом, который вы отправляли.
>
>
> SS> У меня есть некий асинхронный движок. Допустим я по какому-то внешнему
> SS> событию (например запуск) хочу подконектиться к другому серверу и
> SS> послать ему строчку.
> SS> Для этого я говорю своему асинхронному движку: конектись(адрес, порт,
> SS> за 10 секунд).
> SS> В это время движок делает соответствующий системный вызов... и таки
> SS> да, никаких таймаутов. Но он либо
> SS>   а) устанавливает еще один колбек от системы - на время 10 секунд и
> SS> ждет какое событие наступит раньше (реализация таймаута)
> SS>   б) либо периодически очень-очень часто теребит ОС, мол, а не
> SS> наступило ли там событие. И в процессе этого теребления инкрементит
> SS> прошедшее время. И опять-таки получается реализация таймаута.
>
> SS> Конечно может быть есть еще куча гораздо более лучших способов. Я
> SS> просто хотел сказать, что если в сисколе select/epoll/etc нет понятия
> SS> таймаута - это не значит, что асихнронные приложения их не ждут.
> SS> Асинхронщина без реализации таймаутов (в любом виде, мне правда пофигу
> SS> на каком уровне и как именно) - бесполезна.
>
> SS> 2008/12/31  <postmaster at softsearch.ru>:
>>> Здравствуйте, Sergey.
>>>
>>> Вы не совсем правильно представляете работу асинхронных приложений.
>>> Они не ждут таймаут, они получают сообщения от ОС и по ним что-то делают.
>>>
>>>> Почитал тред про CGI в nginx, утром обсуждали смежную задачку с колегом.
>>>> Только у меня идея была написать всю асинхронщину на питоне, а в
>>>> реальной жизни мы используем nginx + fastcgi на питоне.
>>>
>>>> И в общем идея примерно такая.
>>>> Есть некий слой "А" асинхронной обработки запросов снаружи (повторюсь,
>>>> сейчас его роль офигительно выполняет nginx).
>>>> "А" знает, что в его распоряжении имеется, скажем 100 бекендов - 100
>>>> процессов. Думаю, оптимальное количество можно определить для
>>>> конкретной материнки и проца. (RFC)
>>>> Приходит внешний запрос от клиента. "А" здесь быстро принимает запрос
>>>> и ищет свободный воркер
>>>> если есть свободный воркер, (RFC)
>>>>    помечает его как занятый
>>>>    асинхронно шлёт запрос ему,
>>>> (и продолжает работать дальше)
>>>> если нет свободного воркера
>>>>     ждем таймаут, если в течение таймаута свободного воркера не
>>>> появилось - возвращаем клиенту "таймаут" (RFC, кажется, nginx именно
>>>> так и умеет)
>>>> когда воркер вернул результат
>>>>     отдаём клиенту,
>>>>     помечаем воркер как свободный.
>>>
>>>> К этому счастью нужно прикрутить админку бекендов с графиками и
>>>> полуавтоматическим контроллером пула воркеров, то есть чтоб некий
>>>> третий процесс контроллировал сколько нужно прибить лишних воркеров,
>>>> сколько нужно открыть новых (RFC).
>>>
>>>> Получится наверно что-то вроде веб-части Google AppEngine.
>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>>  postmaster                          mailto:postmaster at softsearch.ru
>>>
>>>
>>>
>
>
>
>
> --
> Best regards,
>  Sergey
>
>
>