Forum: NGINX nginx-0.7.54

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Igor S. (Guest)
on 2009-05-01 23:19
(Received via mailing list)
Changes with nginx 0.7.54                                        01 May
2009

    *) Feature: the ngx_http_image_filter_module.

    *) Feature: the "proxy_ignore_headers" and "fastcgi_ignore_headers"
       directives.

    *) Bugfix: a segmentation fault might occur in worker process, if an
       "open_file_cache_errors off" directive was used; the bug had
       appeared in 0.7.53.

    *) Bugfix: the "port_in_redirect off" directive did not work; the
bug
       had appeared in 0.7.39.

    *) Bugfix: improve handling of "select" method errors.

    *) Bugfix: of "select() failed (10022: ...)" error in nginx/Windows.

    *) Bugfix: in error text descriptions in nginx/Windows; the bug had
       appeared in 0.7.53.
Jérôme Loyet (Guest)
on 2009-05-02 08:34
(Received via mailing list)
2009/5/1 Igor S. <removed_email_address@domain.invalid>:
>
>    *) Bugfix: the "port_in_redirect off" directive did not work; the bug
>       had appeared in 0.7.39.
>
>    *) Bugfix: improve handling of "select" method errors.
>
>    *) Bugfix: of "select() failed (10022: ...)" error in nginx/Windows.
>
>    *) Bugfix: in error text descriptions in nginx/Windows; the bug had
>       appeared in 0.7.53.
>

thx igor !
Chris W. (Guest)
on 2009-05-02 18:57
Igor S. wrote:
> Changes with nginx 0.7.54                                        01 May
> 2009
>     *) Bugfix: improve handling of "select" method errors.
>
>     *) Bugfix: of "select() failed (10022: ...)" error in nginx/Windows.
>
>     *) Bugfix: in error text descriptions in nginx/Windows; the bug had
>        appeared in 0.7.53.
hi Igor

I run 0.7.54 nginx/windows, but I found the nginx don't work at all when
I set "worker_processes  4".

command "telnet 127.0.0.1 80" is ok, but IE can't open
"http://127.0.0.1", it wait untill time expired.  and  no error in
error.log.
Igor S. (Guest)
on 2009-05-02 20:04
(Received via mailing list)
On Sat, May 02, 2009 at 04:57:36PM +0200, Chris Wan wrote:

>
> I run 0.7.54 nginx/windows, but I found the nginx don't work at all when
> I set "worker_processes  4".
>
> command "telnet 127.0.0.1 80" is ok, but IE can't open
> "http://127.0.0.1", it wait untill time expired.  and  no error in
> error.log.

Try

events {
   accept_mutex  off;
}

In my tests only one process receives select() notifcaitons about new
connections.
Chris W. (Guest)
on 2009-05-02 20:50
Igor S. wrote:
> On Sat, May 02, 2009 at 04:57:36PM +0200, Chris Wan wrote:
>
>>
>> I run 0.7.54 nginx/windows, but I found the nginx don't work at all when
>> I set "worker_processes  4".
>>
>> command "telnet 127.0.0.1 80" is ok, but IE can't open
>> "http://127.0.0.1", it wait untill time expired.  and  no error in
>> error.log.
>
> Try
>
> events {
>    accept_mutex  off;
> }
>
> In my tests only one process receives select() notifcaitons about new
> connections.
thx, It work.

I want to know more information about this directives.

nginx wiki:
accept_mutex
Syntax: accept_mutex [ on | off ]
Default: on
nginx uses accept mutex to serialize accept() syscalls.


I notice you used to say:
Workers try to hold accept_mutex which
allows only one worker to get new connections notification and to call
accept(). You can switch accept_mutex off, then all scheduling will be
done by OS scheduler via accept() call. "

but apache said:
/* On some architectures it's safe to do unserialized accept()s in the
single
 * Listen case.  But it's never safe to do it in the case where there's
 * multiple Listen statements.  Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 * when it's safe in the single Listen case.
 */
Igor S. (Guest)
on 2009-05-03 00:20
(Received via mailing list)
On Sat, May 02, 2009 at 06:50:25PM +0200, Chris Wan wrote:

> >
> I want to know more information about this directives.
> allows only one worker to get new connections notification and to call
> accept(). You can switch accept_mutex off, then all scheduling will be
> done by OS scheduler via accept() call. "
>
> but apache said:
> /* On some architectures it's safe to do unserialized accept()s in the
> single
>  * Listen case.  But it's never safe to do it in the case where there's
>  * multiple Listen statements.  Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  * when it's safe in the single Listen case.
>  */

If Listen is single Apache workers just call blocking accept().
If Listen are several worker can not just call blocking accept() on one
listening socket. It calls select() for all listening sockets instead,
and then calls accept() for returned socket.

nginx workers always use select/kqueue/epoll/etc. before accept().

OS may wake all processes waiting on accept() and select(), this is
called
http://en.wikipedia.org/wiki/Thundering_herd_problem
This is a problem if you have a lot of workers as in Apache (hundreds
and more), but this insensible if you have just several workers as nginx
usually has. Therefore turning accept_mutex off is as scheduling
incoming
connection by OS via select/kqueue/epoll/etc (but not accept().
Igor S. (Guest)
on 2009-05-03 00:20
(Received via mailing list)
On Sat, May 02, 2009 at 09:18:51PM +0400, Igor S. wrote:

> > >> "http://127.0.0.1", it wait untill time expired.  and  no error in
> > thx, It work.
> > I notice you used to say:
> >  * when it's safe in the single Listen case.
> http://en.wikipedia.org/wiki/Thundering_herd_problem
> This is a problem if you have a lot of workers as in Apache (hundreds
> and more), but this insensible if you have just several workers as nginx
> usually has. Therefore turning accept_mutex off is as scheduling incoming
> connection by OS via select/kqueue/epoll/etc (but not accept().

Also, unless I am mistaken Apache2/Windows uses IOCP at least on NT.
Weibin Y. (Guest)
on 2009-05-04 10:45
(Received via mailing list)
> Changes with nginx 0.7.54                                        01 May 2009
>
>     *) Feature: the ngx_http_image_filter_module.
Thanks for your hard work.

I find a tiny bug. With the option of ./configure --help, I can't find
the option of |--with-http_image_filter_module.|
Igor S. (Guest)
on 2009-05-04 11:29
(Received via mailing list)
On Mon, May 04, 2009 at 02:32:49PM +0800, Weibin Y. wrote:

>
> >Changes with nginx 0.7.54                                        01 May
> >2009
> >
> >    *) Feature: the ngx_http_image_filter_module.
> Thanks for your hard work.
>
> I find a tiny bug. With the option of ./configure --help, I can't find
> the option of |--with-http_image_filter_module.|

Yes, I have found this shortly after release.
郭振立 (Guest)
on 2009-05-04 18:41
(Received via mailing list)
> Subject: nginx-0.7.54
>
> Changes with nginx 0.7.54 01 May 2009

>
> Igor S.
> http://sysoev.ru/en/
>


Thank you very much for your so hard work. And I'm looking forward to
recieve your multi-thread IOCP based version.

Cheers.



Robert Kwok
This topic is locked and can not be replied to.