I am getting errors when using ngx.socket.udp or ngx.timer in an access_by_lua_file environment

chmd · 2014-07-15T23:16:57+00:00

Can we stop resurrecting a years-old thread? 😁On Jun 19, 2018, at 19:01, Rob Kay <ar...@gmail.com> wrote:I used https://github.com/hamishf...

I am getting errors when using ngx.socket.udp or ngx.timer in an access_by_lua_file environment

chmd

Hi,

I am unable to send udp messages in a n access_by_lua_file
environment. I tried using a timer, as an alternative, but in both
cases, I get a 500 error and the following error log:

- attempt to index field 'udp' (a nil value)
- attempt to index field 'timer' (a nil value)

If I understand the doc, both of these api calls should be available
in the access_by_lua* context.

I just checked my version of nginx, and I got:
nginx version: nginx/1.2.1

The wiki says ngx.socket.udp was added in v0.5.7 r, and ngx.timer in v0.8.0.

Do you have an idea why I can't do that?

Cheers,
Christophe-Marie

agentzh

Hello!

On Tue, Jul 15, 2014 at 8:16 AM, Christophe-Marie Duquesne wrote:
>
> - attempt to index field 'udp' (a nil value)
> - attempt to index field 'timer' (a nil value)
>

Such errors are usually a clear sign for an old ngx_lua module version
that lacks the corresponding API functions.

> If I understand the doc, both of these api calls should be available
> in the access_by_lua* context.
>

As long as your ngx_lua version also qualifies.

> I just checked my version of nginx, and I got:
> nginx version: nginx/1.2.1
>
> The wiki says ngx.socket.udp was added in v0.5.7 r, and ngx.timer in v0.8.0.
>

The wiki you're referring to should be ngx_lua module's version. So
the version numbers here like "v0.5.7" and "v0.8.0" are ngx_lua
module's version instead of the nginx core's.

Check the version of your ngx_lua module instead.

BTW, to prevent such problems, it is recommended to always use the
latest version of the OpenResty bundle:

    http://openresty.org/#Download

Regards,
-agentzh

chmd

Thank you very much for your answer!

Unfortunately, I don't think I can easily install the latest openresty
bundle. My development has to target debian wheezy, and I should avoid
installing a custom version (custom as opposed to officially
packaged). So unless there is no other solution, I am constrained to
only use standard debian packages .

I am thinking about a workaround, using socat. Basically, I would run
externally e.g.
socat PIPE:/var/run/nginx.pipe UDP-SENDTO:192.168.1.2:8145
and from the lua, I would write data to /var/run/nginx.pipe
(My use case requires to continuously write data to the same address)

Do you think it is a bad idea? Can do that and still be non blocking?

Regards,
Christophe-Marie

On Tue, Jul 15, 2014 at 9:19 PM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Jul 15, 2014 at 8:16 AM, Christophe-Marie Duquesne wrote:
>>
>> - attempt to index field 'udp' (a nil value)
>> - attempt to index field 'timer' (a nil value)
>>
>
> Such errors are usually a clear sign for an old ngx_lua module version
> that lacks the corresponding API functions.
>
>> If I understand the doc, both of these api calls should be available
>> in the access_by_lua* context.
>>
>
> As long as your ngx_lua version also qualifies.
>
>> I just checked my version of nginx, and I got:
>> nginx version: nginx/1.2.1
>>
>> The wiki says ngx.socket.udp was added in v0.5.7 r, and ngx.timer in v0.8.0.
>>
>
> The wiki you're referring to should be ngx_lua module's version. So
> the version numbers here like "v0.5.7" and "v0.8.0" are ngx_lua
> module's version instead of the nginx core's.
>
> Check the version of your ngx_lua module instead.
>
> BTW, to prevent such problems, it is recommended to always use the
> latest version of the OpenResty bundle:
>
>     http://openresty.org/#Download
>
> Regards,
> -agentzh.

chmd

Nevermind, I already see a problem with that approach: socat might not
split the messages as I want, so when writing

{"message":"hello world"}

I might end up sending 2 messages:

1: {"message"
2: :"hello world"}



On Wed, Jul 16, 2014 at 9:26 AM, Christophe-Marie Duquesne <c...@chmd.fr> wrote:
> Thank you very much for your answer!
>
> Unfortunately, I don't think I can easily install the latest openresty
> bundle. My development has to target debian wheezy, and I should avoid
> installing a custom version (custom as opposed to officially
> packaged). So unless there is no other solution, I am constrained to
> only use standard debian packages .
>
> I am thinking about a workaround, using socat. Basically, I would run
> externally e.g.
> socat PIPE:/var/run/nginx.pipe UDP-SENDTO:192.168.1.2:8145
> and from the lua, I would write data to /var/run/nginx.pipe
> (My use case requires to continuously write data to the same address)
>
> Do you think it is a bad idea? Can do that and still be non blocking?
>
> Regards,
> Christophe-Marie
>
> On Tue, Jul 15, 2014 at 9:19 PM, Yichun Zhang (agentzh)
> <age...@gmail.com> wrote:
>> Hello!
>>
>> On Tue, Jul 15, 2014 at 8:16 AM, Christophe-Marie Duquesne wrote:
>>>
>>> - attempt to index field 'udp' (a nil value)
>>> - attempt to index field 'timer' (a nil value)
>>>
>>
>> Such errors are usually a clear sign for an old ngx_lua module version
>> that lacks the corresponding API functions.
>>
>>> If I understand the doc, both of these api calls should be available
>>> in the access_by_lua* context.
>>>
>>
>> As long as your ngx_lua version also qualifies.
>>
>>> I just checked my version of nginx, and I got:
>>> nginx version: nginx/1.2.1
>>>
>>> The wiki says ngx.socket.udp was added in v0.5.7 r, and ngx.timer in v0.8.0.
>>>
>>
>> The wiki you're referring to should be ngx_lua module's version. So
>> the version numbers here like "v0.5.7" and "v0.8.0" are ngx_lua
>> module's version instead of the nginx core's.
>>
>> Check the version of your ngx_lua module instead.
>>
>> BTW, to prevent such problems, it is recommended to always use the
>> latest version of the OpenResty bundle:
>>
>>     http://openresty.org/#Download
>>
>> Regards,
>> -agentzh.

agentzh

Hello!

On Wed, Jul 16, 2014 at 12:26 AM, Christophe-Marie Duquesne wrote:
> Unfortunately, I don't think I can easily install the latest openresty
> bundle. My development has to target debian wheezy, and I should avoid
> installing a custom version (custom as opposed to officially
> packaged). So unless there is no other solution, I am constrained to
> only use standard debian packages .
>

You can always install openresty (from source) to any location that
you want, like /opt/openresty or even under your /home. Because I
cannot control the so called "standard debian packages", I cannot
really help you keep up to date.

In the near future, I may set up a server to distribute the "official
openresty debian package" ("official" as to openresty rather than to
debian), as well as for some other common Linux distributions.

> I am thinking about a workaround, using socat. Basically, I would run
> externally e.g.
> socat PIPE:/var/run/nginx.pipe UDP-SENDTO:192.168.1.2:8145
> and from the lua, I would write data to /var/run/nginx.pipe

Among other things, your "workaround" will block your nginx worker
process's event loop on I/O and ruin the performance.

Best regards,
-agentzh

chmd

Hi,

On Wed, Jul 16, 2014 at 9:18 PM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> You can always install openresty (from source) to any location that
> you want, like /opt/openresty or even under your /home. Because I
> cannot control the so called "standard debian packages", I cannot
> really help you keep up to date.

Thank you for your recommendations! Actually, I found is a more recent
version of nginx-extras in the wheezy-backports repository. It is
official enough to satisfy my basic maintainance requirements.

> In the near future, I may set up a server to distribute the "official
> openresty debian package" ("official" as to openresty rather than to
> debian), as well as for some other common Linux distributions.

This would be very nice!

>> I am thinking about a workaround, using socat. Basically, I would run
>> externally e.g.
>> socat PIPE:/var/run/nginx.pipe UDP-SENDTO:192.168.1.2:8145
>> and from the lua, I would write data to /var/run/nginx.pipe
>
> Among other things, your "workaround" will block your nginx worker
> process's event loop on I/O and ruin the performance.

That is what I feared. I am happy that there is an easy and non hacky
workaround!

Cheers,
Christophe-Marie