On Wed, Aug 3, 2011 at 2:47 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:
> Hello!
>
> On Wed, Aug 03, 2011 at 01:53:30AM +0800, David Yu wrote:
>
> > On Wed, Aug 3, 2011 at 1:50 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >
> > > Hello!
> > >
> > > On Wed, Aug 03, 2011 at 01:42:13AM +0800, David Yu wrote:
> > >
> > > > On Wed, Aug 3, 2011 at 1:36 AM, Maxim Dounin <mdounin@mdounin.ru>
> wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Tue, Aug 02, 2011 at 04:24:45PM +0100, António P. P. Almeida
> wrote:
> > > > >
> > > > > > On 1 Ago 2011 17h07 WEST, mdounin@mdounin.ru wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > JFYI:
> > > > > > >
> > > > > > > Last week I posted patch to nginx-devel@ which adds keepalive
> > > > > > > support to various backends (as with upstream keepalive
> module),
> > > > > > > including fastcgi and http backends (this in turn means nginx
> now
> > > > > > > able to talk HTTP/1.1 to backends, in particular it now
> > > > > > > understands chunked responses). Patch applies to 1.0.5 and
> 1.1.0.
> > > > > > >
> > > > > > > Testing is appreciated.
> > > > > > >
> > > > > > > You may find patch and description here:
> > > > > > >
> > > > > > >
> > > http://mailman.nginx.org/pipermail/nginx-devel/2011-July/001057.html
> > > > > > >
> > > > > > > Patch itself may be downloaded here:
> > > > > > >
> > > > > > > http://nginx.org/patches/patch-nginx-keepalive-full.txt
> > > > > > >
> > > > > > > Upstream keepalive module may be downloaded here:
> > > > > > >
> > > > > > > http://mdounin.ru/hg/ngx_http_upstream_keepalive/
> > > > > > > http://mdounin.ru/files/ngx_http_upstream_keepalive-0.4.tar.gz
> > > > > > >
> > > > > >
> > > > > > So *either* we use the patch or use the module. Correct?
> > > > >
> > > > > No, to keep backend connections alive you need module *and* patch..
> > > > > Patch provides foundation in nginx core for module to work with
> > > > > fastcgi and http.
> > > > >
> > > > With a custom nginx upstream binary protocol, I believe multiplexing
> will
> > > > now be possible?
> > >
> > > ENOPARSE, sorry.
> > >
> > After some googling ...
> > ENOPARSE is a nerdy term. It is one of the standard C library error codes
> > that can be set in the global variable "errno" and stands for Error No
> > Parse. Since you didn't get it, I can thus conclude that unlike me you
> are probably
> > a normal, well adjusted human being ;-)
>
> Actually, this definition isn't true: there is no such error code,
> it's rather imitation. The fact that author of definition claims
> it's real error indicate that unlike me, he is normal, well
> adjusted human being. ;)
>
> > Now I get it. Well adjusted I am.
>
> Now you may try to finally explain what you mean to ask in your
> original message. Please keep in mind that your are talking to
> somebody far from being normal and well adjusted. ;)
>
> Maxim Dounin
>
> p.s. Actually, I assume you are talking about fastcgi
> multiplexing.
Nope not fastcgi multiplexing. Multiplexing over a custom/efficient nginx
binary protocol.
Where requests sent to upstream include a unique id w/c the upstream will
also send on response.
This allows for asychronous, out-of-bands, messaging.
I believe this is what mongrel2 is trying to do now ... though as an http
server, it is nowhere near as robust/stable as nginx.
If nginx implements this (considering nginx already has a lot of market
share), it certainly would bring more developers/users in (especially the
ones needing async, out-of-bands request handling)
Short answer is: no, it's still not possible.
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
--
When the cat is away, the mouse is alone.
- David Yu
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
