Ngx_lua + proxy_next_upstream

Hello,

I have configured:

  1. ngx_lua as rewrite_by_lua_file
  2. lua returns upstream
  3. Nginx connects to the upstream
    Works perfectly.

The question is how can I archive proxy_next_upstream.
Preferably I would like to return to lua with a error reason.
If the only way is to return several servers in upstream from lua, how
to
do so ?

I’m currently setting ngx.var.upstream and then proxy_pass
http://$upstream.
I suppose the simplest method would be to set the $upstream in correct
format. But what about my preferably method?

Cheers,
Jędrzej Nowak

Hello!

On Wed, Sep 18, 2013 at 6:09 AM, Jedrzej Nowak wrote:

The question is how can I archive proxy_next_upstream.
Preferably I would like to return to lua with a error reason.
If the only way is to return several servers in upstream from lua, how to do
so ?

If you want to return the control back to Lua and let your Lua code do
the upstream retries or something, then you should use the
ngx.location.capture() API instead to initiate an Nginx subrequest to
ngx_proxy:

http://wiki.nginx.org/HttpLuaModule#ngx.location.capture

Regards,
-agentzh

Hey,

Thanks for your reply. Is there any good “example” of thing what I want
to
archive ?

Shall I create something like:

location @blah {

here the “normal” configuration for LB

}

location / {

here the LUA logic

probably with share_all_vars=true

subrequest to @blah

}

Is something like that recommended or how should it be done ?

Pozdrawiam
Jędrzej Nowak

On Fri, Sep 20, 2013 at 2:34 AM, Yichun Z. (agentzh)

Hello!

On Tue, Sep 24, 2013 at 2:35 AM, Jedrzej Nowak wrote:

The question is how can I do NOT redirect ?

Well, “rewrite … break” is not a redirect. It is just an internal
URI rewrite. That’s all.

I tried with @test instead of
/test but no success. Is there any other way to do that ?

Named locations can only work with internal redirects. They do not
support Nginx subrequests. You can ask the Nginx team to add support
for that to the Nginx core.

[...]
ngx.var.upstream = "192.168.1.10:9999"
res = ngx.location.capture('/test' .. ngx.var.request_uri,

{share_all_vars = true})
[…]

Please note that setting the “share_all_vars” to true for your
subrequests are genreally a bad idea. Because there could be really
bad side effects. In your example, all you need is to enable the
“copy_all_vars” option.

BTW, you may want to post such questions to the openresty-en mailing
list instead:

https://groups.google.com/group/openresty-en

Best regards,
-agentzh

Yeah, I meant rewrite obviously… I would still prefer to not have even
rewrite if it’s possible.

I wonder why share_all_vars is not safe. Any serious consideration /
example / use case ? Why it’s better to copy them instead ? (What about
memory footprint etc).

And I will probably send the questions to openresty group too.

Thanks for your replies.

Ok, I still have some problems. It works but not perfectly.

My config is:

    location /test {
             internal;
             rewrite  /test(.*)  $1 break;
             proxy_buffering             off;
             proxy_set_header            Host $host;
             proxy_set_header            X-Forwarded-For

$proxy_add_x_forwarded_for;
proxy_redirect off;
proxy_connect_timeout 10;
proxy_send_timeout 30;
proxy_read_timeout 30;
proxy_pass http://$upstream;
}

    location / {
             set $upstream "";
             set $app_name "";
             content_by_lua_file conf/lua_proxy.lua;
    }

The question is how can I do NOT redirect ? I tried with @test instead
of
/test but no success. Is there any other way to do that ?

lua looks like:

[...]
ngx.var.upstream = "192.168.1.10:9999"
res = ngx.location.capture('/test' .. ngx.var.request_uri,

{share_all_vars = true})
[…]

Pozdrawiam
Jędrzej Nowak

Hello!

On Tue, Sep 24, 2013 at 3:39 PM, pigmej wrote:

Yeah, I meant rewrite obviously… I would still prefer to not have even rewrite
if it’s possible.

It’s not worth saving at all. If you take an on-CPU Flame Graph for
your loaded Nginx worker processes, you’ll never even see it on the
graph. You’d better put your optimization efforts on something that is
truly measurable.

See also

I wonder why share_all_vars is not safe. Any serious consideration / example /
use case ? Why it’s better to copy them instead ? (What about memory footprint
etc).

Because of side effects involved in sharing variables between the
parent request and the subrequest. You can find such scary examples in
my Nginx tutorials (still under work!):

http://openresty.org/download/agentzh-nginx-tutorials-en.html

And I will probably send the questions to openresty group too.

It’s just that you’re more likely to get more responses more quickly
for such questions. That’s all.

Regards,
-agentzh