worker with infinite loop

[Anton K]

Hello.

I need to run one worker in infinite polling loop using ubus uloop (it use epoll_pwait on ubus socket). Same time, I need other workers (threads) doing some periodic tasks (timer-based, doing block operation – ioctl's on dev, something very similar to healthcheck but spending a lot of time on ioctls) and other workers accepting requests via http or a stream.

How it could be achieved?

[Dirk Feytons]

uloop assumes it is the main event loop. This fundamentally clashes
with openresty where the main event loop is the nginx one and for
obvious performance reasons all socket operations need to be done
through that one.


Dirk F.

> --
> You received this message because you are subscribed to the Google Groups
> "openresty-en" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openresty-en...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Anton K]

Ok, I see. I can rewrite this part to use JSON requests instead of ubus message passing.

How can I start only one-two or three worker(s) with periodical tasks (which may blocks for a while, in case of HW failure and recovery, it might takes up to minute) while other workers will serve usual http? The "init_worker_by_lua*" called each time when worker has started. And "init_by_lua*" called once on nginx startup. However, as far as I understand, it doesn't allow "ngx.timer.at".

среда, 15 июня 2016 г., 16:39:35 UTC+3 пользователь Dirk Feytons написал:

[Robert Paprocki]

ngx.timer.at is indeed allowed in the context of init_worker: https://github.com/openresty/lua-nginx-module#ngxtimerat

However, being aware that a worker being blocked does not necessarily mean that all other HTTP requests will be handled by other workers. In general it's very bad to implement this kind of architecture that could block the whole worker; it would be better to move any blocking actions to a separate process, and have your worker poll for results asynchronously.

[Anton K]

As this issue's conversation stated:

   https://github.com/openresty/lua-nginx-module/issues/330

it's better to use shared dict to track a current worker number.

среда, 15 июня 2016 г., 17:08:30 UTC+3 пользователь Anton K написал:

[Yichun Zhang (agentzh)]

Hello!

The idea of blocking a particular nginx worker process for one's own
housekeeping work is not new in the OpenResty community. And we were
actually discussing the ngx.worker.no_listen() Lua API in ngx_lua:

https://groups.google.com/forum/#!msg/openresty/F33LRHv3nZ0/waa_zxKgHwAJ

Regards,
-agentzh

[Anton K]

Hello,

is there any progress with such functionality? Thank you!

среда, 22 июня 2016 г., 8:10:46 UTC+3 пользователь agentzh написал: