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 &gby shaun - Nginx Mailing List - English
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, > hby shaun - Nginx Mailing List - English
Piotr Sikora Wrote: ------------------------------------------------------- > > I figure the trickiest part will be building > those requests and getting > > them in to state that's usable by nginx. > > This is already done, so there isn't much to > figure out ;) > > Just create "independent" request: > r = ngx_supervisord_init(pool, uscf);by shaun - Nginx Mailing List - English
Piotr Sikora Wrote: ------------------------------------------------------- > If you want to go that route then I believe that > you could re-use a lot of > code from ngx_supervisord[1]. Most of the code > below line 993 ("nginx <> > supervisord communication" comment) does exacly > what you need (creating > "fake request", connecting to upby shaun - Nginx Mailing List - English
agentzh Wrote: ------------------------------------------------------- > On Thu, Nov 19, 2009 at 5:54 PM, agentzh wrote: > > > > It's weird that the client sees the response > header and body after the > > slowest subrequest finishes. It seems that the > response has been > > buffered in the last few output filters somehow. > Please ensure that > &by shaun - Nginx Mailing List - English
agentzh Wrote: ------------------------------------------------------- > On Wed, Nov 18, 2009 at 4:24 PM, agentzh wrote: > > 4. In your output filter, first check if there's > a ctx object > > associated with the current request. If yes, > then you're filtering one > > of the subrequests that your content handler > starts. So now simply > > buffer theby shaun - Nginx Mailing List - English
agentzh Wrote: ------------------------------------------------------- > On Wed, Nov 18, 2009 at 2:30 PM, shaun wrote: > > Here's a description of what I'm hoping to > accomplish: > > Here's a proposal for your consideration: > > 1. You need a content handler and an output filter > to work together. > 2. Use a content handler to issue all the > subreqby shaun - Nginx Mailing List - English
Here's a description of what I'm hoping to accomplish: A request comes in and, based on the content of the GET arguments or POST data, one or more backends will be selected. The request (with a bit of modification) will then be proxied to all of the selected backends. These backends might return data immediately or could hang waiting for data for a indeterminate amount of time. I'd like to retby shaun - Nginx Mailing List - English
![]() |
![]() |
![]() |
![]() |
![]() |