Re: Когда может возникнуть ситуация, что rev->instance != instance?
On Friday 27 September 2013 21:26:13 megalodon wrote: > Все, осознал: воркер, получив очередной event_list[] и обрабатывая > некоторое событие может закрыть также и другой дескриптор, связанный с > обрабатываемым, причем событие с этого другого закрываемого дескриптора > также могло попасть в этот event_list[], и пока мы до него доберемся, > структура, которая была связана с ним может быть уже использована под > новое соединение. Именно так. -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
Все, осознал: воркер, получив очередной event_list[] и обрабатывая некоторое событие может закрыть также и другой дескриптор, связанный с обрабатываемым, причем событие с этого другого закрываемого дескриптора также могло попасть в этот event_list[], и пока мы до него доберемся, структура, которая была связана с ним может быть уже использована под новое соединение. Спасибо всем!!! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,243182,243217#msg-243217 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
On Friday 27 September 2013 20:45:27 megalodon wrote:
> Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как
> добрались до обработки событий". Но где в промежутке между epoll_wait() и
> итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
> потенциально закрыть сокет?
"событий, с ним связанных"
[...]
>
> for (i = 0; i < events; i++) {
> c = event_list[i].data.ptr;
>
> instance = (uintptr_t) c & 1;
> c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
>
> rev = c->read;
>
> if (c->fd == -1 || rev->instance != instance) {
>
> Если c->fd не равно -1 и если rev->instance не совпадает с instance, то
> получается, что где-то между строками
> events = epoll_wait(ep, event_list, (int) nevents, timer); и
>.
> if (c->fd == -1 || rev->instance != instance) {
> произошло инвертирование этого поля?
>
Между этими строками ещё происходят итерации цикла, которые итерирует
по другим событиям, возвращенным из epoll_wait().
Соединение может быть закрыто не только по событиям, непосредственно
связанным с дескриптором этого соединения, но и по другим событиям,
как это происходит, например, в случае проксирования, когда у нас есть
два соединения: с бэкендом и с клиентом, события могут одновременно
происходить на обоих соединениях, при этом событие на одном, может
приводить к закрытия другого.
Всё становится ещё сложнее, когда у нас есть, например, какой-нибудь
SSI, который асинхронно пошел сразу на несколько бэкендов. Представьте,
что в этот момент клиент закрыл соединение и мы по этому событию
автоматически закрываем все соединения с бэкендами, открытыми SSI-модулем
для обслуживания запроса от этого клиента.
>
> "Несоответствие instance возможно, когда мы уже закрыли соединение, про
> которое нам сообщает ядро." Получается, что пока процесс спал, будучи
> заблокированным на шаге epoll_wait(), каким-то образом сокет закрылся и
> структура ngx_connection_t была использована повторно, но как, ведь процесс
> был заблокирован?
>
Нет, не так. Максим в своем ответе уже привел пример. Смотрите и мой выше.
Соединение могло быть закрыто, а равно как открыто другое соединение при
обработки других событий в цикле.
--
Валентин Бартенев
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как
добрались до обработки событий". Но где в промежутке между epoll_wait() и
итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
потенциально закрыть сокет?
events = epoll_wait(ep, event_list, (int) nevents, timer);
err = (events == -1) ? ngx_errno : 0;
if (flags & NGX_UPDATE_TIME || ngx_event_timer_alarm) {
ngx_time_update();
}
if (err) {
.
}
if (events == 0) {
.
}
ngx_mutex_lock(ngx_posted_events_mutex);
for (i = 0; i < events; i++) {
c = event_list[i].data.ptr;
instance = (uintptr_t) c & 1;
c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
rev = c->read;
if (c->fd == -1 || rev->instance != instance) {
Если c->fd не равно -1 и если rev->instance не совпадает с instance, то
получается, что где-то между строками
events = epoll_wait(ep, event_list, (int) nevents, timer); и
.
if (c->fd == -1 || rev->instance != instance) {
произошло инвертирование этого поля?
"Несоответствие instance возможно, когда мы уже закрыли соединение, про
которое нам сообщает ядро." Получается, что пока процесс спал, будучи
заблокированным на шаге epoll_wait(), каким-то образом сокет закрылся и
структура ngx_connection_t была использована повторно, но как, ведь процесс
был заблокирован?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,243182,243215#msg-243215
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: leaky bucket limit_req
> Получается, что если в течение 1мс пришли 2 запроса, то второй будет дропнут, > даже если в конфиге будет прописано 2000r/s? Только при условии, что burst был исчерпан. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,10518,243214#msg-243214 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
Hello! On Fri, Sep 27, 2013 at 11:32:20AM -0400, megalodon wrote: > Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из > своих структур и не будет по нему отслеживать события. > > Ход событий в общем: воркер блокируется на epoll_wait(), по истечении > тайм-аута либо по получении nevent событий, воркер просыпается и в цикле > перебирает эти события. Допустим, встретилось событие на чтение и recv() > вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из > структур подсистемы epoll, также в массив cycle->free_connections > возвращается структура ngx_connection_t. > > Я не понимаю такой момент: почему ядро потом может вернуть событие для уже > закрытого сокета? Ядро возвращает более одного события за раз. А соединение может быть закрыто не только при обработке событий от этого соединения, но и при обработке событий от другого соединения. Простейший пример: от бекенда пришёл ответ, мы его прочитали, отправили клиенту, закрыли оба соединения - и с бекендом, и с клиентом. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
On Friday 27 September 2013 19:32:20 megalodon wrote: > Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из > своих структур и не будет по нему отслеживать события. > > Ход событий в общем: воркер блокируется на epoll_wait(), по истечении > тайм-аута либо по получении nevent событий, воркер просыпается и в цикле > перебирает эти события. Допустим, встретилось событие на чтение и recv() > вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из > структур подсистемы epoll, также в массив cycle->free_connections > возвращается структура ngx_connection_t. > > Я не понимаю такой момент: почему ядро потом может вернуть событие для уже > закрытого сокета? > Оно его уже вернуло, ещё до закрытия. Там есть комментарий: /* * the stale event from a file descriptor * that was just closed in this iteration */ Ключевой момент тут "this iteration", вся речь идет о текущей итерации обработки событий. Мы могли закрыть соединение до того, как добрались до обработки событий, с ним связанных (первая проверка). Могли закрыть соединение на read-событии, а следом у нас идет write (вторая проверка). -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из своих структур и не будет по нему отслеживать события. Ход событий в общем: воркер блокируется на epoll_wait(), по истечении тайм-аута либо по получении nevent событий, воркер просыпается и в цикле перебирает эти события. Допустим, встретилось событие на чтение и recv() вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из структур подсистемы epoll, также в массив cycle->free_connections возвращается структура ngx_connection_t. Я не понимаю такой момент: почему ядро потом может вернуть событие для уже закрытого сокета? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,243182,243207#msg-243207 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Анонс] Модуль nginx-http-rdns
On 27.09.2013 17:02, Peter B. Pokryshev wrote: Я про тоже, а в чем защита от ддоса? Вот от ддоса: https://github.com/kyprizel/testcookie-nginx-module Да, этим мы тоже пользуемся :-) Нет утверждений, что nginx-http-rdns — самодостоточное решение защиты от DDoS'а. Может использоваться как одна из «шестеренок» в комплексной системе защиты (в комбинации с различными средствами). -- Дмитрий Шурупов, руководитель проектов ЗАО «Флант» http://flant.ru/ +7 (495) 721-10-27, доб. 442 +7 (926) 120-77-71 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Анонс] Модуль nginx-http-rdns
On Fri, 27 Sep 2013 16:52:40 +0400 Dmitry Shurupov wrote: > On 27.09.2013 16:50, Peter B. Pokryshev wrote: > > Привет. Нет обратки - значит бот? > Далеко не факт. Я про тоже, а в чем защита от ддоса? Вот от ддоса: https://github.com/kyprizel/testcookie-nginx-module >Например, помогает (вместе с лимитами по количеству > запросов) делать исключения для поисковых ботов и других известных служб. > > -- > Дмитрий Шурупов, > руководитель проектов ЗАО «Флант» > http://flant.ru/ > +7 (495) 721-10-27, доб. 442 > +7 (926) 120-77-71 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ^^ С уважением, Пётр Покрышев ValueHost ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Анонс] Модуль nginx-http-rdns
On 27.09.2013 16:50, Peter B. Pokryshev wrote: Привет. Нет обратки - значит бот? Далеко не факт. Например, помогает (вместе с лимитами по количеству запросов) делать исключения для поисковых ботов и других известных служб. -- Дмитрий Шурупов, руководитель проектов ЗАО «Флант» http://flant.ru/ +7 (495) 721-10-27, доб. 442 +7 (926) 120-77-71 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Анонс] Модуль nginx-http-rdns
On Fri, 27 Sep 2013 16:29:50 +0400 Dmitry Shurupov wrote: > Всем привет! > > > Представляю вниманию сообщества модуль nginx-http-rdns, реализующий > простой механизм контроля доступа по доменному имени клиента (имя > определяется по результатам выполнения обратного DNS-запроса). > > Модуль nginx-http-rdns: > * выполняет преобразование IP-адреса клиента в доменное имя; > * позволяет создавать простые списки контроля доступа (разрешить / > запретить) на основе полученного доменного имени; > * поддерживает модуль rewrite для динамического включения / выключения > внутри директив if. > > Используем в production уже продолжительное время — помогает нам в > борьбе с DDoS-атаками. > Привет. Нет обратки - значит бот? > Документация на русском языке: http://flant.ru/projects/nginx-http-rdns > Документация на английском языке: http://wiki.nginx.org/HttpRdnsModule > (она же есть в README на GitHub) > > Проект на GitHub: https://github.com/flant/nginx-http-rdns > Будем рады патчам и сообщениям о багах. > > > -- > Дмитрий Шурупов, > руководитель проектов ЗАО «Флант» > http://flant.ru/ > +7 (495) 721-10-27, доб. 442 > +7 (926) 120-77-71 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[Анонс] Модуль nginx-http-rdns
Всем привет! Представляю вниманию сообщества модуль nginx-http-rdns, реализующий простой механизм контроля доступа по доменному имени клиента (имя определяется по результатам выполнения обратного DNS-запроса). Модуль nginx-http-rdns: * выполняет преобразование IP-адреса клиента в доменное имя; * позволяет создавать простые списки контроля доступа (разрешить / запретить) на основе полученного доменного имени; * поддерживает модуль rewrite для динамического включения / выключения внутри директив if. Используем в production уже продолжительное время — помогает нам в борьбе с DDoS-атаками. Документация на русском языке: http://flant.ru/projects/nginx-http-rdns Документация на английском языке: http://wiki.nginx.org/HttpRdnsModule (она же есть в README на GitHub) Проект на GitHub: https://github.com/flant/nginx-http-rdns Будем рады патчам и сообщениям о багах. -- Дмитрий Шурупов, руководитель проектов ЗАО «Флант» http://flant.ru/ +7 (495) 721-10-27, доб. 442 +7 (926) 120-77-71 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Когда может возникнуть ситуация, что rev->instance != instance?
Hello!
On Fri, Sep 27, 2013 at 03:32:53AM -0400, megalodon wrote:
> Добрый день.
>
> В функции ngx_epoll_process_events() есть такой участок кода:
>
> for (i = 0; i < events; i++) {
> c = event_list[i].data.ptr;
>
> instance = (uintptr_t) c & 1;
> c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
>
> rev = c->read;
>
> if (c->fd == -1 || rev->instance != instance) {
>.
> }
> .
> }
>
> Условие rev->instance != instance будет проверяться, если c->fd != -1, т.е.
> в случае когда дескриптор не был закрыт.
> c->fd устанавливается в -1 в функциях: ngx_close_connection() и
> ngx_close_accepted_connection().
> Но rev->instance инвертируется в функции ngx_get_connection(), которая
> вызывается в ngx_event_accept().
>
> Получается, что несоответсвие instance возможно, когда мы не закрыли
> соединение и при этом акцептировали новое и для него была выделена уже
> существующая структура ngx_connection_t ??
Несоответствие instance возможно, когда мы уже закрыли соединение,
про которое нам сообщает ядро, и уже успели использовать структуру
соединения заново для других целей.
--
Maxim Dounin
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx and Jboss AS
Дык установи заголовок Host в что тебе надо... :)
2013/9/27 Vurtatoo
> Всем привет.
> Как передать доменное имя джейбосу, и как его получить?
> Сейчас сервер запущен как демон коммандой ./standalone.sh
>
> Конфиг файл, вернее его часть
> location ~ /myapp/ {
> proxy_pass http://127.0.0.1:8080;
> }
> пытался получить имя домена, по которому обращались , но получал 127.0.0.1
>
> К приложению обращаются по разным урлам, от этоо зависит что показывать.
> Например : http://nginx.org/myapp/ или http://dev.nginx.org/myapp/
>
>
> На пхп всё работает и сервер передаёт.
> там работает
> fastcgi_param SERVER_SOFTWARE
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,243184,243184#msg-243184
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Nginx and Jboss AS
Всем привет.
Как передать доменное имя джейбосу, и как его получить?
Сейчас сервер запущен как демон коммандой ./standalone.sh
Конфиг файл, вернее его часть
location ~ /myapp/ {
proxy_pass http://127.0.0.1:8080;
}
пытался получить имя домена, по которому обращались , но получал 127.0.0.1
К приложению обращаются по разным урлам, от этоо зависит что показывать.
Например : http://nginx.org/myapp/ или http://dev.nginx.org/myapp/
На пхп всё работает и сервер передаёт.
там работает
fastcgi_param SERVER_SOFTWARE
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,243184,243184#msg-243184
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Когда может возникнуть ситуация, что rev->instance != instance?
Добрый день.
В функции ngx_epoll_process_events() есть такой участок кода:
for (i = 0; i < events; i++) {
c = event_list[i].data.ptr;
instance = (uintptr_t) c & 1;
c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
rev = c->read;
if (c->fd == -1 || rev->instance != instance) {
.
}
.
}
Условие rev->instance != instance будет проверяться, если c->fd != -1, т.е.
в случае когда дескриптор не был закрыт.
c->fd устанавливается в -1 в функциях: ngx_close_connection() и
ngx_close_accepted_connection().
Но rev->instance инвертируется в функции ngx_get_connection(), которая
вызывается в ngx_event_accept().
Получается, что несоответсвие instance возможно, когда мы не закрыли
соединение и при этом акцептировали новое и для него была выделена уже
существующая структура ngx_connection_t ??
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,243182,243182#msg-243182
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
