Proxy Retry Logic

[Eugaia]

Hi,

On 22/12/2010 21:26, Sirsiwal, Umesh wrote:
>
> All,
>
> I am trying to write a module which uses a number of subrequests to 
> talk to backend servers. Combines the responses and sends them back to 
> the client. The communication with the backend server is using HTTP 
> and I am using proxy_pass for that.
>
> The peculiarity in our setup is that on failure-retry I need to use a 
> different URI than the original request. Current, proxy reinit request 
> does not regenerate request hence cannot be used for the purpose. I 
> tried using the error_page in the subrequest location to point to a 
> different location. But, it seems that the error_page is not evaluated 
> on subrequest. The only option I can think of is for my module to 
> detect error and issue a new subrequest.
>
> Is this the best solution for this problem? Will that affect 
> subrequest response concatenation?
>
I think you can do this now using the echo module 
(http://wiki.nginx.org/HttpEchoModule), subrequests and try_files

e.g.

location    /main {
     echo_location    /sub1;    # could also be echo_location_async
     echo_location    /sub2;    # (ditto)
}

location    /sub1 {
     try_files ...
}

location    /sub 2 {
     try_files ...
}

Where ... in try_files are the separate proxy locations.

I'm not certain (and I've not tested / looked at the code) what happens 
when a proxied request returns a non-200 response, but I am assuming 
that try_files tries the next location on the list.  If it does (and it 
should if it doesn't), and you know the URL of the new testing location, 
then this method should work.

A word of caution about using both synchronous and asynchronous echo_ 
commands next to one another.  There used to be (and I'm not sure if 
they've been fixed yet or not) issues with this.  Use either sync or 
async combined and you should be fine (async is probably a better 
option, since it's likely to give a faster response to the client in 
this case).

Cheers,

Marcus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-devel/attachments/20101223/17f1de02/attachment.html>