[openresty-en] Abort ngx.timer.at?

rpaprocki · 2015-03-02T17:17:34+00:00

Hi folks! I am pleased to announce the new formal release, 1.7.10.1, of the OpenResty bundle: http://openresty.org/#Download Special thanks go to all...

[openresty-en] Abort ngx.timer.at?

rpaprocki

Hello,

We have a situation in which a variable is set under given conditions (stored in a shared dict), and is given an expire time (typically 10-30 seconds, but maybe several minutes); this expiration is handled via ngx.timer.at. It is possible for this expire time to be extended if the same resource is called under the same conditions, so in that case we run a second timer and restamp the variable with the new expire timestamp (when the first timer runs it checks its expected expire timestamp vs. the actual expire timestamp, and if they do not match, it does not expire). So, it's easy to overrun the number of max timers if many clients request resources that are controlled by this logic. Is there any way to cancel pending timers that have not executed so we avoid maxing this level out?

me_0943

Hi!

Is it possible for you to use the built in expiry of the shared dict key instead? (http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT.set)

Or do you need to do something when it expires?

Cheers,

Chris

On Monday, March 2, 2015 at 9:17:36 AM UTC, rpaprocki wrote:

Hello,

We have a situation in which a variable is set under given conditions (stored in a shared dict), and is given an expire time (typically 10-30 seconds, but maybe several minutes); this expiration is handled via ngx.timer.at. It is possible for this expire time to be extended if the same resource is called under the same conditions, so in that case we run a second timer and restamp the variable with the new expire timestamp (when the first timer runs it checks its expected expire timestamp vs. the actual expire timestamp, and if they do not match, it does not expire). So, it's easy to overrun the number of max timers if many clients request resources that are controlled by this logic. Is there any way to cancel pending timers that have not executed so we avoid maxing this level out?

rpaprocki

Aha, see, this is why mailing lists exist! I had totally skimmed over that section while reading the docs, silly me! This is perfect. My only concern when first looking at this was how the expire time would be handled when the same key is written again, and it appears to behave exactly as I need- the expire time is essentially 'reset', based on the timestamp of the most recent key set.

Out of sheer curiosity at this point, what is the mechanism that handles this expiration? I don't see anything in the nginx debug log exactly when the expire time occurs, only a 'slab free' when the next get -after- the expire time occurs- is this some kind of lazy expiration that doesn't rely on timers then, but an internal timestamp?

Thanks again Chris, much appreciated :)

On Mon, Mar 2, 2015 at 1:58 AM, Chris Tanner <...@itschr.is> wrote:

Hi!

Is it possible for you to use the built in expiry of the shared dict key instead? (http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT.set)
Or do you need to do something when it expires?

Cheers,
Chris

On Monday, March 2, 2015 at 9:17:36 AM UTC, rpaprocki wrote:
Hello,

We have a situation in which a variable is set under given conditions (stored in a shared dict), and is given an expire time (typically 10-30 seconds, but maybe several minutes); this expiration is handled via ngx.timer.at. It is possible for this expire time to be extended if the same resource is called under the same conditions, so in that case we run a second timer and restamp the variable with the new expire timestamp (when the first timer runs it checks its expected expire timestamp vs. the actual expire timestamp, and if they do not match, it does not expire). So, it's easy to overrun the number of max timers if many clients request resources that are controlled by this logic. Is there any way to cancel pending timers that have not executed so we avoid maxing this level out?

agentzh

Hello!

On Mon, Mar 2, 2015 at 5:31 AM, Robert Paprocki wrote:
> Out of sheer curiosity at this point, what is the mechanism that handles
> this expiration? I don't see anything in the nginx debug log exactly when
> the expire time occurs, only a 'slab free' when the next get -after- the
> expire time occurs- is this some kind of lazy expiration that doesn't rely
> on timers then, but an internal timestamp?
>

Yes, it's lazy expiration, as found in other key-value cache servers
like memcached. Otherwise it's just too expensive to expire keys.

Regards,
-agentzh