how to use lua-resty-http or lua-resty-http-simple in balancer_by_lua?

liupengwyy · 2016-08-31T16:37:32+00:00

I have a content_by_lua in my config file that calls a function do_stuff() in a lua file.The function essentially calls ngx.location.capture and I have the c...

how to use lua-resty-http or lua-resty-http-simple in balancer_by_lua?

liupengwyy

Hi,

I know that lua-resty-http or lua-resty-http-simple is used to send http request. I want to use it to access upstream server for my own load balancing policy computation. I try lua-resty-http-simple, then in the log I see the message below:

2016/08/31 15:53:33 [error] 31549#31549: *1 failed to run balancer_by_lua*: ...ginx_src/lua-resty-http-simple/lib/resty/http/simple.lua:326: API disabled in the context of balancer_by_lua*
stack traceback:
[C]: in function 'tcp'
...ginx_src/lua-resty-http-simple/lib/resty/http/simple.lua:326: in function 'request'

And the example of lua-resty-http and lua-resty-http-simple are for content_by_lua, which could be used in location context.

Thanks.
liupeng

aapo.talvensaari

On Wednesday, 31 August 2016 11:37:32 UTC+3, Peng Liu wrote:

2016/08/31 15:53:33 [error] 31549#31549: *1 failed to run balancer_by_lua*:

https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

"This Lua code execution context does not support yielding, so Lua APIs that may yield (like cosockets and "light threads") are disabled in this context".

So it is not supported there. You have to find a work-a-round. Can you cache the data somehow that you don't need to call cosockets there?

liupengwyy

Hi,

As the data (such as the workload of upstream server, it is a factor for the load balance) is dynamically changed during the application execution, so I need to access it at some specific time, for example doing load balance.

Thanks

On Wednesday, August 31, 2016 at 7:57:28 PM UTC+8, Aapo Talvensaari wrote:

On Wednesday, 31 August 2016 11:37:32 UTC+3, Peng Liu wrote:
2016/08/31 15:53:33 [error] 31549#31549: *1 failed to run balancer_by_lua*:

https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

"This Lua code execution context does not support yielding, so Lua APIs that may yield (like cosockets and "light threads") are disabled in this context".

So it is not supported there. You have to find a work-a-round. Can you cache the data somehow that you don't need to call cosockets there?

rpaprocki

One alternative could be to asynchronously poll your upstream bodes using a recurring timer, and store the data in a shm dict or lrucache? Or you can simply elect to use a phase handler that supports cosocket usage, such as rewrite or access phase handlers.

On Aug 31, 2016, at 17:56, Peng Liu <liup...@gmail.com> wrote:

Hi,

As the data (such as the workload of upstream server, it is a factor for the load balance) is dynamically changed during the application execution, so I need to access it at some specific time, for example doing load balance.

Thanks

On Wednesday, August 31, 2016 at 7:57:28 PM UTC+8, Aapo Talvensaari wrote:

On Wednesday, 31 August 2016 11:37:32 UTC+3, Peng Liu wrote:
2016/08/31 15:53:33 [error] 31549#31549: *1 failed to run balancer_by_lua*:

https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

"This Lua code execution context does not support yielding, so Lua APIs that may yield (like cosockets and "light threads") are disabled in this context".

So it is not supported there. You have to find a work-a-round. Can you cache the data somehow that you don't need to call cosockets there?

.

liupengwyy

@rpaprocki,

For me, polling upstream node is a better choice using a timer, how to do that in nginx lua module?

Thanks

On Thursday, September 1, 2016 at 9:01:26 AM UTC+8, rpaprocki wrote:

One alternative could be to asynchronously poll your upstream bodes using a recurring timer, and store the data in a shm dict or lrucache? Or you can simply elect to use a phase handler that supports cosocket usage, such as rewrite or access phase handlers.

On Aug 31, 2016, at 17:56, Peng Liu <liupe...@gmail.com> wrote:

Hi,

As the data (such as the workload of upstream server, it is a factor for the load balance) is dynamically changed during the application execution, so I need to access it at some specific time, for example doing load balance.

Thanks

On Wednesday, August 31, 2016 at 7:57:28 PM UTC+8, Aapo Talvensaari wrote:

On Wednesday, 31 August 2016 11:37:32 UTC+3, Peng Liu wrote:
2016/08/31 15:53:33 [error] 31549#31549: *1 failed to run balancer_by_lua*:

https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

"This Lua code execution context does not support yielding, so Lua APIs that may yield (like cosockets and "light threads") are disabled in this context".

So it is not supported there. You have to find a work-a-round. Can you cache the data somehow that you don't need to call cosockets there?

.

rpaprocki

Hi,

On Wed, Aug 31, 2016 at 7:16 PM, Peng Liu <liup...@gmail.com> wrote:

@rpaprocki,

For me, polling upstream node is a better choice using a timer, how to do that in nginx lua module?

Have a look at the ngx.timer.at documentation, which has an example of creating a recurring time:

https://github.com/openresty/lua-nginx-module#ngxtimerat

And a few different options for storing data:

https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

https://github.com/openresty/lua-nginx-module#ngxshareddict

https://github.com/openresty/lua-resty-lrucache

You should be able to just move your business logic into a separate function that is recurringly called via ngx.timer.at, write the necessary data to the storage environment of your choice, and then select the appropriate upstream node in balance_by_lua by reading from that persistent storage instead of calling your business logic function.

liupengwyy

Thanks. At present I implement it in rewrite_by_lua block. Which method is more efficient?

On Friday, September 2, 2016 at 6:03:55 AM UTC+8, rpaprocki wrote:

Hi,

On Wed, Aug 31, 2016 at 7:16 PM, Peng Liu <liupe...@gmail.com> wrote:
@rpaprocki,

For me, polling upstream node is a better choice using a timer, how to do that in nginx lua module?

Have a look at the ngx.timer.at documentation, which has an example of creating a recurring time:

https://github.com/openresty/lua-nginx-module#ngxtimerat

And a few different options for storing data:

https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker
https://github.com/openresty/lua-nginx-module#ngxshareddict
https://github.com/openresty/lua-resty-lrucache

You should be able to just move your business logic into a separate function that is recurringly called via ngx.timer.at, write the necessary data to the storage environment of your choice, and then select the appropriate upstream node in balance_by_lua by reading from that persistent storage instead of calling your business logic function.

jonathan

On Wednesday, August 31, 2016 at 9:01:26 PM UTC-4, rpaprocki wrote:

One alternative could be to asynchronously poll your upstream bodes using a recurring timer, and store the data in a shm dict or lrucache? Or you can simply elect to use a phase handler that supports cosocket usage, such as rewrite or access phase handlers.

You can also make an LAN-only API endpoint on the openresty server, and POST as needed to update the native dict/cache.

agentzh

Hello!

On Thu, Sep 1, 2016 at 8:00 PM, Peng Liu wrote:
> Thanks. At present I implement it in rewrite_by_lua block. Which method is
> more efficient?
>

ngx.timer.at() is asynchronous, which means that you cannot easily get
the result of your timer handler in the Lua handler (balancer_by_lua*)
creating the timer.

Using an earlier phase handlers like rewrite_by_lua* and
access_by_lua* is the right way to go, which is also documented
officially. You can pass the result easily to balancer_by_lua* via the
ngx.ctx API, for example. This is the recommended approach.

Regards,
-agentzh

rpaprocki

On Sun, Sep 4, 2016 at 12:53 PM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Thu, Sep 1, 2016 at 8:00 PM, Peng Liu wrote:
> Thanks. At present I implement it in rewrite_by_lua block. Which method is
> more efficient?
>

ngx.timer.at() is asynchronous, which means that you cannot easily get
the result of your timer handler in the Lua handler (balancer_by_lua*)
creating the timer.

Using an earlier phase handlers like rewrite_by_lua* and
access_by_lua* is the right way to go, which is also documented
officially. You can pass the result easily to balancer_by_lua* via the
ngx.ctx API, for example. This is the recommended approach.

Well, yes, if you want the to poll the upstreams at every request. The idea suggested by using a timer was to only poll at an interval and use a local data store to determine the appropriate upstream in the balancer handler. It's less efficient to make a separate synchronous request to each upstream node on every single request, which was the original context here.