Skip to content
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

Merged
merged 6 commits into from
May 17, 2023

Conversation

liverpool8056
Copy link
Contributor

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

  • [Implement ...]

Issue reference

#10691

CHANGELOG.md Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Contributor

@ADD-SP ADD-SP left a 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()
Copy link
Contributor

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.

Copy link
Contributor Author

@liverpool8056 liverpool8056 May 4, 2023

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

Copy link
Contributor

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.

Copy link
Contributor

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.

@liverpool8056
Copy link
Contributor Author

@ADD-SP Yes, I just close them when there is something wrong with the connections.

@liverpool8056 liverpool8056 force-pushed the fix/sockets-release branch from 4b6e449 to ecb7276 Compare May 4, 2023 08:48
Copy link
Contributor

@ADD-SP ADD-SP left a 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.

Copy link
Contributor

@ADD-SP ADD-SP left a 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

kong/reports.lua Outdated Show resolved Hide resolved
@liverpool8056 liverpool8056 requested a review from oowl May 15, 2023 11:49
@liverpool8056 liverpool8056 force-pushed the fix/sockets-release branch from 94ed018 to 600a5a2 Compare May 15, 2023 11:53
liverpool8056 and others added 6 commits May 16, 2023 17:55
…cessary

For those sockets created inside the schedule of timer-ng, the sockets
must be closed explicitly. More details, please refer to:
[#10691](#10691)
Co-authored-by: Chrono <chrono_cpp@me.com>
Co-authored-by: Chrono <chrono_cpp@me.com>
Co-authored-by: Jun Ouyang <ouyangjun1999@gmail.com>
@liverpool8056 liverpool8056 force-pushed the fix/sockets-release branch from 600a5a2 to 1c1ac4e Compare May 16, 2023 09:55
@windmgc windmgc merged commit 9a50b1b into master May 17, 2023
@windmgc windmgc deleted the fix/sockets-release branch May 17, 2023 03:04
[#10790](https://github.com/Kong/kong/pull/10790)
- **loggly & tcp-log & udp-log**: fix a potential issue that could cause socket leaks.
Copy link
Member

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

kikito added a commit that referenced this pull request May 19, 2023
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

#
locao pushed a commit that referenced this pull request May 19, 2023
…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

#
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants