*) 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.
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.
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
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
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
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().
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. Thundering herd problem - Wikipedia
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.