-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
fix(loggly&tcp-log&udp-log&reports): close sockets explicitly when necessary #10783
Conversation
8e80164
to
73a46d5
Compare
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.
For the TCP socket, would it be more proper to replace socket:close()
with socket:setkeepalive()
?
JUST A SUGGESTION.
@@ -27,13 +27,15 @@ local function log(premature, conf, message) | |||
local ok, err = sock:connect(host, port) | |||
if not ok then | |||
kong.log.err("failed to connect to ", host, ":", tostring(port), ": ", err) | |||
sock:close() |
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'm a little curious, is it still need to explicitly call close
when an error occurs? Most languages don't seem to need to do that, and it doesn't seem to do so in the official examples I've seen.
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.
A reasonable concern. Please let us know if you have some conclusion about it, @oowl
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.
Fatal errors in cosocket operations always automatically close the current connection (note that, read timeout error is the only error that is not fatal), and if you call close on a closed connection, you will get the "closed" error.
https://github.com/openresty/lua-nginx-module#ngxsockettcp
Even if the socket will be closed when a fatal occurred, I think closing a failed socket explicitly is a good style.
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 think closing a failed socket explicitly is a good style.
I have the opposite opinion, I think such code is not clean enough and feels very verbose.
@ADD-SP Yes, I just close them when there is something wrong with the connections. |
4b6e449
to
ecb7276
Compare
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 think writing tests for this PR is not worth until we find a proper, right, non-flaky way to write the test.
We can't find a great way to test this fix now. if we just write test to follow the PR review process, it will introduce some bad code in our test set. The final target of the PR review process is for a better code base, writing tests is for that, and refusing bad test code is also for that.
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.
Duplicate #10783 (review) due to bad network
94ed018
to
600a5a2
Compare
Co-authored-by: Chrono <chrono_cpp@me.com>
Co-authored-by: Chrono <chrono_cpp@me.com>
Co-authored-by: Jun Ouyang <ouyangjun1999@gmail.com>
600a5a2
to
1c1ac4e
Compare
[#10790](https://github.com/Kong/kong/pull/10790) | ||
- **loggly & tcp-log & udp-log**: fix a potential issue that could cause socket leaks. |
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.
Note that this change was added to the wrong version in the changelog - it should have gone into #unreleased
I revised the changes one by one. Besides trivial changes in punctuation/order: #10783 (Reports: fix a potential issue that could cause socket leaks. and **loggly & tcp-log & udp-log**: fix a potential issue that could cause socket leaks.) was resolved after code freeze and was not backported to 3.3 - its changelog entry was put in the wrong place #
…0909) I revised the changes one by one. Besides trivial changes in punctuation/order: #10783 (Reports: fix a potential issue that could cause socket leaks. and **loggly & tcp-log & udp-log**: fix a potential issue that could cause socket leaks.) was resolved after code freeze and was not backported to 3.3 - its changelog entry was put in the wrong place #
Summary
For those sockets created inside the schedule of timer-ng, the sockets must be closed explicitly.
More details, please refer to: #10691
Checklist
Full changelog
Issue reference
#10691