-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(timerng) integrate the lua-resty-timer-ng
#8912
Conversation
-- old_post(self, n) | ||
-- ngx.sleep(0) | ||
-- end | ||
-- end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this be enabled in case opf legacy timers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This patch looks like it's meant to fix some OpenResty bug, and nothing tested wrong when I disabled it. It doesn't seem to be timer-related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a fix for a lot of flaky tests. @javierguerragiraldez might know better if this can be removed or not.
Here's the underlying issue: openresty/lua-resty-core#337
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that "some openresty bug" is actually in the docs (https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/semaphore.md#post):
Releases n (default to 1) "resources" to the semaphore instance.
This will not yield the current running "light thread".
but most code seems to assume that yield, and so we get a long runs before the woken-up thread gets some CPU time. if the new time library does include that yield, then yes, this one should be removed. if not, then it does help a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that is not the bug, I would expect the current coro to NOT yield. That is fine. The problem is that if there is nothing else to do, OpenResty simply exits without EVER resuming the released thread.
@@ -31,6 +31,6 @@ describe("kong quit", function() | |||
assert(helpers.kong_exec("quit --wait 2 --prefix " .. helpers.test_conf.prefix)) | |||
ngx.update_time() | |||
local duration = ngx.now() - start | |||
assert.is.near(2, duration, 1.6) | |||
assert.is.near(2, duration, 5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does exiting now take more time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the new timer library starts many OpenResty's timers, each timer waits for a semaphore (one-second timeout). Increasing to five seconds is mainly in dealing with the slow CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but please note that semaphores are buggy, see the other comment and this issue: openresty/lua-resty-core#337
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think this would make any PM happy. slow exits can be considered a low-priority bug. make sure to raise an issue/ticket to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ADD-SP let's make sure this behaviour is recorded in JIRA and fix before final release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have created the FT-3010.
596abcd
to
77d6fe1
Compare
407f609
to
b63f1d0
Compare
8d75eec
to
978b301
Compare
2565d4c
to
79e8f92
Compare
369dd66
to
68adc31
Compare
215fbd6
to
f7cbea3
Compare
As discussed with @ADD-SP offline, we will first merge in this one, and iterrate on the tests side; Qiqi is working on a determinisitic approach in spec/helpers to ensure timer jobs are executed instead of simply add ngx.sleep. But I don't want to block on this PR and let it become a last minute merge just because of this. cc @javierguerragiraldez @Tieske how do you feel? (Though you don't leave Request Changes, but I'm asking since your review comments express worry-ness on it) |
* fix(plugin_servers) bypass timer library * feat(AdminAPI) add `/timer` route * feat(conf) add new config `legacy_timer_mechanism` (boolean) * chore(rockspec) add `resty.timerng` as dependency * tests(*) add `wait_timers_*()` for helper * tests(plugin/zipkin) fix * tests(unit/db/cache_warmup) fix * tests(integration/cmd/quit) fix * tests(integration/hybrid_mode/ocsp) fix * tests(plugin/rate-limiting/access) fix * tests(integration/db/query-semaphore) fix * tests(integration/admin/timers) add tests for `http://kong_admin/timers` * tests(integration/cmd/start_stop) fix * tests(integration/proxy/router) fix * docs(CHANGELOG) update Co-authored-by: Mayo <i@shoujo.io> Co-authored-by: Wangchong Zhou <fffonion@gmail.com>
b4ad69d
to
a48033a
Compare
Summary
Integrating https://github.com/Kong/lua-resty-timer-ng into Kong-CE.
Full changelog
/timers
routeresty.timerng
as dependencyhttp://kong_admin/timers
Response of
http://kong_admin/timers