Parallel subrequests for multi-source long polling?

shaun nginx-forum at
Sun Nov 22 05:12:09 MSK 2009

shaun Wrote:
> agentzh Wrote:
> --------------------------------------------------
> -----
> > All the addon module's .o files are put under a
> > single directory,
> > namely, objs/addon/src/. If two modules use two
> > different versions of
> > your ngx_blah_blah_blah.c, then one of the .o
> will
> > get overridden and
> > break that module's certain assumption. This
> will
> > not be an issue,
> > however, if version numbers are coded into the
> .c
> > file names, like
> > ngx_blah_blah_blah_v1.c :)
> > 
> > Personally I like the second method more
> because
> > it reduces one
> > dependency on the end-user's side :)
> > 
> > Cheers,
> > -agentzh
> Distributing versioned .c/.h files seems the
> cleanest.

Piotr / Agentzh,

I moved all the subrequest specific stuff in to a separate module, available here:  

Piotr, this uses some of your fake request code (see src/fake_request.c).  I added your license at the front of that file, since most of that code is yours.  

At the moment, this module has one publicly available function:  ngx_indep_subreq_fetch().  You give it a parsed ngx_url_t and a callback function and it creates the request, sets up the upstream, kicks off the proxying, and then calls your callback with the subrequest during the finalize_request stage. 

You can pass in a struct of function pointers that the module will use at the various upstream callback points.  Right now, you'll definitely need a function for create_request(), otherwise the request will have no request buffers to pass along.  Having something that sets r->upstream->request_bufs to "GET / HTTP/1.0\r\n\r\n" is enough to get it to actually successfully proxy and return data, assuming your fetch callback sends the upstream->buffer to the main request and finalizes it. 

Pretty rough right now, but it's a good start. 


Posted at Nginx Forum:,23767,24761#msg-24761

More information about the nginx mailing list