*) Feature: the ngx_http_upstream_keepalive module.
*) Feature: the "proxy_http_version" directive.
*) Feature: the "fastcgi_keep_conn" directive.
*) Feature: the "worker_aio_requests" directive.
*) Bugfix: if nginx was built --with-file-aio it could not be run on
Linux kernel which did not support AIO.
*) Bugfix: in Linux AIO error processing.
Thanks to Hagai A..
*) Bugfix: reduced memory consumption for long-lived requests.
*) Bugfix: the module ngx_http_mp4_module did not support 64-bit MP4
"co64" atom.
On Tue, Sep 20, 2011 at 03:22:25PM +0400, Igor S. wrote:
Changes with nginx 1.1.4 20 Sep 2011
*) Feature: the ngx_http_upstream_keepalive module.
[…]
*) Bugfix: reduced memory consumption for long-lived requests.
[…]
Note to module developers: this release introduces several API
changes which may affect 3rd party modules. Please review svn
commits for details. Most intresting commits are:
On Tue, Sep 20, 2011 at 08:29:06AM -0400, Sirsiwal, Umesh wrote:
Thanks to both of you. Great work.
If I understand correctly, the only way to use
upstream_keepalive module is with upstream module. This implies
I cannot use upstream_keepalive where the upstream is identified
by a variable. For example:
If I understand correctly, the only way to use upstream_keepalive module
is with upstream module. This implies I cannot use upstream_keepalive
where the upstream is identified by a variable. For example:
proxy_pass http://$host$request_uri;
Is my understand correct? Is there a way around this restriction?
When is it ported to stable version? I means the upstream keep-alive feature?
Most likely never: there are several API changes which are
required for this. Breaking API in stable is a bad thing.
At some point 1.1.x will just become stable
major.minor.revision
nginx will not use odd minor version numbers to denote development
releases and even minor version numbers to denote stable releases?
1.0.x - stable branch
1.1.x - devel branch
1.2.x - stable branch
1.3.x - devel branch
and so on?
if not - it will be many confusion, which version 1.1.x is stable,
and which nginx 1.2.x version is devel or stable.
use odd minor version numbers to denote development releases
and even minor version numbers to denote stable releases -
imho is very useful and clear version numbering scheme.
(but looks like apache/squid/haproxy not use this scheme)
On Wed, Sep 21, 2011 at 01:51:34PM +0300, Gena M. wrote:
if not - it will be many confusion, which version 1.1.x is stable,
and which nginx 1.2.x version is devel or stable.
use odd minor version numbers to denote development releases
and even minor version numbers to denote stable releases -
imho is very useful and clear version numbering scheme.
Yes, I’ve already proposed this to Igor to simplify stable vs.
devel distinction. He isn’t convinced yet, but we have some time
to think about this.