aggregating multiple upstream responses before finalizing the down stre am request

François Battail fb at francois.battail.name
Fri May 16 18:48:43 MSD 2008


dchapiesky at ... <dchapiesky at ...> writes:

> The focus of my module is to -compare- results from multiple parallel 
> servers, not monitoring upstream server health.   
> The closer-to-real-world-example is: 
> old server A with old crappy hard to maintain (hmmm Apache anyone) 
> database app new server B with new shiny happy easy to configure 
> (***nginx***) front end to new shiny database app
> new server C with nginx (and my fault tolerance module) 
> acting as proxy to servers A and B
> If the process of migrating the database app from server A to B breaks 
> the results returned by the app, then tell me with a POST to my own 
> server... cause we gotta know if the two apps are not returning the 
> same data....
> When the new server B is --verified-- to be equivilent to old server A, 
> then we can retire server A --- but not before.   

Well, that way I understand, but I think it's still a waste of ressources, why
don't you put a X-Header on the application server like
X-My-Application-Version="x.y.z" and issue an HTTP HEAD request on a special url
each hour by a script outside Nginx to do the monitoring, except if there are
some points I don't understand, it make no sense for me to monitor something
like this for *each* request, since it's not request related.

> It seems to me that I could send the request to be injected to the port 
> I'm listening on... duh. But I'm incurring the overhead of going out to 
> the tcp/ip stack and OS and then returning.  Surely there is a way of 
> chaining a new request into the queue without having to resort to that.  
> I know this is a dumb question but it is puzzling me.  

It's not a dumb question; it's a complex question. The main problem is to get
back the context when you have the event and without interfering with the normal
processing of Nginx; it takes me weeks to find and validate a clean approach.
The idea of spoofing, injecting or to fake data in a software like Nginx is IMHO
very dangerous.

Best regards.






More information about the nginx mailing list