Forum: NGINX nginx-0.7.55

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.
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-05-06 11:47
(Received via mailing list)
Changes with nginx 0.7.55                                        06 May
2009

    *) Bugfix: the http_XXX parameters in "proxy_cache_use_stale" and
       "fastcgi_cache_use_stale" directives did not work.

    *) Bugfix: fastcgi cache did not cache header only responses.

    *) Bugfix: of "select() failed (9: Bad file descriptor)" error in
       nginx/Unix and "select() failed (10022: ...)" error in
nginx/Windows.

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

    *) Bugfix: fix ngx_http_image_filter_module building errors.

    *) Bugfix: the files bigger than 2G could not be transferred using
       $r->sendfile.
       Thanks to Maxim Dounin.
539ecead12aa07ed8fa9807bcfbf34f1?d=identicon&s=25 郭振立 (Guest)
on 2009-05-06 12:33
(Received via mailing list)
> Changes with nginx 0.7.55 06 May 2009
>
> *) Bugfix: of "select() failed (9: Bad file descriptor)" error in
> nginx/Unix and "select() failed (10022: ...)" error in nginx/Windows.
>


Great work.

Looking forward to recieve your multi-thread IOCP based version.

Robert Kwok
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-05-06 13:29
(Received via mailing list)
On Wed, May 06, 2009 at 06:23:44PM +0800, ?????? wrote:

>
> Looking forward to recieve your multi-thread IOCP based version.

The multi-threads version will take several months.
Ba3a6c32cd38e42bd7bff27d446b62d3?d=identicon&s=25 Ebiss Ebiss (ebiss)
on 2009-05-07 05:02
great work.
I like native windows port.
Thanks
2974d09ac2541e892966b762aad84943?d=identicon&s=25 kevinmkilbride (Guest)
on 2009-05-09 18:29
(Received via mailing list)
There appears to be a bug in 0.7.55 (as well as 0.7.54, and perhaps
others) when serving .flv files.

Connections never free. If you look at the stub_status page, the list of
writers increases without limit. On a completely idle machine,
connections that use the flv module are permanently added to the
"writing" list, no matter how long it has been since the connection was
closed; connections that do not use the flv module increment the other
connection counters, as expected, but do not create lingering "ghost
writers."

The server in question is hosting the flv files from an XFS partition.
The nginx executable has been linked with libhugepages and is fully
loaded in a tlbfs segment. Sendfile is enabled and it makes no
difference what the output buffers parameter is set to. I have tried it
with directio on and off with the same result: with directio on, nginx
leaks buffer memory, increasing the size of its memory image without
limit; with directio off, it would (eventually, if I let it) exhaust
file descriptors.

This problem does not exist for 0.6.36 using the exact same compilation
options, configuration files and spool directory.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,1794,1882#msg-1882
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-05-09 20:01
(Received via mailing list)
Hello!

On Fri, May 08, 2009 at 07:16:27PM -0400, kevinmkilbride wrote:

> There appears to be a bug in 0.7.55 (as well as 0.7.54, and perhaps others) when serving 
.flv files.
>
> Connections never free. If you look at the stub_status page, the list of writers 
increases without limit. On a completely idle machine, connections that use the flv module 
are permanently added to the "writing" list, no matter how long it has been since the 
connection was closed; connections that do not use the flv module increment the other 
connection counters, as expected, but do not create lingering "ghost writers."

Could you please try this patch?
http://article.gmane.org/gmane.comp.web.nginx.russian/24085

Flv module shouldn't be the problem since it doesn't increment
connection counters by itself, but typical usage pattern for flv
may trigger the issue described in the above patch (especially
combined with limit_rate functionality, not sure if you use it).

Maxim Dounin
2974d09ac2541e892966b762aad84943?d=identicon&s=25 kevinmkilbride (Guest)
on 2009-05-11 02:19
(Received via mailing list)
Yes, that fixed it! Many kind thanks to you!

The test files were very large, so the connections were never run to
completion, and rate limiting was used, so both criteria for failure
appeared to be met. I just torture tested your patch and it appears to
completely address the issue.

Thanks again.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,1794,1893#msg-1893
This topic is locked and can not be replied to.