-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Semaphore not cleaned up on request timeout #2422
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
Comments
Would you please create a PR for this issue? |
Sounds good, I'll create a pull request. |
After a ngx.semaphore.wait() call, if the current request is terminated by Nginx due to client_header_timeout or client_body_timeout, the corresponding post() is never executed. As a result, all subsequent attempts to wait() on the same semaphore hang until they time out, because the semaphore count was never restored. openresty#2422
After a ngx.semaphore.wait() call, if the current request is terminated by Nginx due to client_header_timeout or client_body_timeout, the corresponding post() is never executed. As a result, all subsequent attempts to wait() on the same semaphore hang until they time out, because the semaphore count was never restored. openresty/lua-nginx-module#2422
@zhuizhuhaomeng lua-nginx-module: #2426 I didn't send for stream-lua-nginx-module because there is a caution comment like this.
|
From https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/semaphore.md#synchronizing-threads-in-different-contexts, there is : "The same applies to different request contexts as long as these requests are served by the same nginx worker process." Does you change break this? |
@zhuizhuhaomeng In this scenario we’re using ngx.timer.at with a closure before acquiring the semaphore. I’m not sure how to resolve this yet. But this seems similar to this issue. From https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#ngxtimerat |
After a
ngx.semaphore.wait()
call, if the current request is terminated by Nginx due toclient_header_timeout
orclient_body_timeout
, the correspondingpost()
is never executed. As a result, all subsequent attempts towait()
on the same semaphore hang until they time out, because the semaphore count was never restored.1. Reproduce by
client_header_timeout
onssl_certificate_by_lua_block
The first request times out in the SSL phase and never calls
post()
.All subsequent requests hang until their
wait()
deadlines.2. Reproduce by
client_body_timeout
onaccess_by_lua_block
The first slow upload triggers client_body_timeout and never calls
post()
Subsequent uploads hang at
wait()
Proposed Solution
Register a cleanup handler (as done in
ngx_http_file_cache
orngx_http_lua_socket_tcp
) when acquiring the semaphore. If the request is aborted, this handler should callsema:post()
to restore the count.The text was updated successfully, but these errors were encountered: