Long running task using ngx.timer.at

luis.gasca · 2014-10-18T00:32:35+00:00

Hello! On Sat, Oct 11, 2014 at 7:27 AM, Abdul Hakeem wrote: > I hope you don't mind me asking these questions: > > 1. Since OpenResty uses NGINX co...

Long running task using ngx.timer.at

luis.gasca

Hi,

Is it possible to run a long running callback function using ngx.timer.at or should I always schedule the next run using ngx.timer.at inside the callback ?

Something like this:

local delay = 1
local handler


handler = function (premature)
        if premature then
            return
        end


while true
 -- polling some external service with ngx.socket.tcp
 end
end
 
local ok, err = ngx.timer.at(delay, handler)

In my case, I will monitoring a beanstalkd server tube for new jobs.

Thanks,

Luis

agentzh

Hello!

On Fri, Oct 17, 2014 at 9:32 AM,  luis.gasca wrote:
> Is it possible to run a long running callback function using ngx.timer.at or
> should I always schedule the next run using ngx.timer.at inside the callback
> ?
>

Generally the second approach is preferred. One potential problem with
the first approach is that some of the ngx_lua module's Lua API
functions can allocate small memory blocks in the current timer
handler's memory pool which means that these memory blocks will not be
freed until the current timer handler is quit and its pool is
destroyed.

But if you observe no such things as slow leaking with the first
approach in your use case, then the first approach is fine as well :)

In the long run, I'd avoid allocating in the nginx memory pools in all
the Lua API functions provided by ngx_lua.

Regards,
-agentzh

luis.gasca

Hello agentzh,

Thanks for the info. After posting my question I have been analyzing your lua-resty-upstream-healthcheck module and all answers are really here.

So, I recommend browsing this source code to anyone that have doubts about workers, timer and threads in openresty. Great code !

Regards,

Luis

El viernes, 17 de octubre de 2014 20:14:29 UTC+2, agentzh escribió:

Hello!

On Fri, Oct 17, 2014 at 9:32 AM, luis.gasca wrote:
> Is it possible to run a long running callback function using ngx.timer.at or
> should I always schedule the next run using ngx.timer.at inside the callback
> ?
>

Generally the second approach is preferred. One potential problem with
the first approach is that some of the ngx_lua module's Lua API
functions can allocate small memory blocks in the current timer
handler's memory pool which means that these memory blocks will not be
freed until the current timer handler is quit and its pool is
destroyed.

But if you observe no such things as slow leaking with the first
approach in your use case, then the first approach is fine as well :)

In the long run, I'd avoid allocating in the nginx memory pools in all
the Lua API functions provided by ngx_lua.

Regards,
-agentzh