Nginx-1.1.4

Changes with nginx 1.1.4 20 Sep
2011

*) 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.


Igor S.

Hello!

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:

http://trac.nginx.org/nginx/changeset/4115/nginx
(ngx_chain_update_chains() api change)

http://trac.nginx.org/nginx/changeset/4117/nginx
http://trac.nginx.org/nginx/changeset/4118/nginx
http://trac.nginx.org/nginx/changeset/4119/nginx
http://trac.nginx.org/nginx/changeset/4120/nginx
(various upstream module related changes)

Maxim D.

Thanks to both of you,

Boyko

Hello!

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:

proxy_pass http://$host$request_uri;

Is my understand correct?

Yes.

Is there a way around this restriction?

Currently no.

Maxim D.

Great !!

finally, upstream_keepalive is supported!!

2011/9/20 Maxim D. [email protected]

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:

proxy_pass http://$host$request_uri;

Is my understand correct? Is there a way around this restriction?

-Umesh


From: [email protected] [[email protected]] On Behalf Of
Boyko Y. [[email protected]]
Sent: Tuesday, September 20, 2011 8:12 AM
To: [email protected]
Cc: [email protected]
Subject: Re: nginx-1.1.4

Thanks to both of you,

Boyko


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx

Hello!

On Wed, Sep 21, 2011 at 02:58:59AM -0700, Geoge.Q wrote:

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.

Maxim D.

On Sep 21, 2011, at 14:20 , Maxim D. wrote:

Hello!

On Wed, Sep 21, 2011 at 02:58:59AM -0700, Geoge.Q wrote:

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 :slight_smile:


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

On 21.09.2011 13:26, Igor S. wrote:

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 :slight_smile:

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)


Best regards,
Gena

Hello!

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.

Maxim D.

When is it ported to stable version? I means the upstream keep-alive
feature?

Thanks
George

2011/9/20, Maxim D. [email protected]:

Maxim D.


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx


ҵƶ豸

Hello Nginx U.s,

I just released Nginx 1.1.4 For Windows http://goo.gl/WzEeA (32-bit and
64-bit)

These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Official Windows binaries are at nginx.org

Thanks,
Kevin

Kevin W.
kworthington (at] gmail {dot) com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs