-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Add read timeout to socket_listener #2571
Conversation
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.
To be consistent with the rest of telegraf, we should use an internal.Duration
for the duration.
Perhaps we should have a default though to avoid half open sockets. What do you think @phemmer ?
## Read deadline (timeout). | ||
## Only applies to stream sockets (e.g. TCP). | ||
## 0 (default) is unlimited. | ||
# read_deadline = 30 |
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 this should be timeout
, the reason is that it is a relative time where a deadline would be absolute and I think the "read" part is implied because of the input type.
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.
Well maybe read_timeout
is better, naming is so hard :)
Hrm, hard question. I think I lean more towards no default. If the socket being left open and idle is a problem, then I would say it's up to the sender to shut it down, not the recipient. In fact the recipient shutting it down can cause data loss if it shuts it down while a message is in transit. So yeah, definitely no default. Oh, and we should never have a half-open socket. Once the sender closes their side, telegraf shuts down its side. |
Nevermind, yes it's valid, but different use case. For datagram we only have a single socket. It's not TCP where we have a separate socket for every connection. We don't want to shut down the whole socket if it's idle. |
What distinguishes a half-open socket from a dead connection? |
Half-open is when one side has issued a Dead connection can happen on a full-open, or half-open. Without TCP keep alives, the recipient will never notice if a connection is severed uncleanly (no FIN/RST packet sent. E.G. sender's power cord pulled). With the TCP keep alive, one side sends an empty packet, and the other side responds with an ACK. No response means dead connection. |
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.
Go ahead an update the CHANGELOG.md file as well.
@@ -112,6 +117,7 @@ type SocketListener struct { | |||
ServiceAddress string | |||
MaxConnections int | |||
ReadBufferSize int | |||
ReadTimeout int |
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.
Sorry, I should have been more clear, this is the value that should be an internal.Duration
. This will allow people to specify the timeout like "30s", so make sure to update the README as well.
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.
No, that's me. Sorry for that.
-Rename timeout parameter -Use internal.Duration
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 we need to SetReadDeadline before the first read.
@@ -78,6 +80,9 @@ func (ssl *streamSocketListener) read(c net.Conn) { | |||
for _, m := range metrics { | |||
ssl.AddFields(m.Name(), m.Fields(), m.Tags(), m.Time()) | |||
} | |||
if ssl.ReadTimeout.Duration > 0 { | |||
c.SetReadDeadline(time.Now().Add(ssl.ReadTimeout.Duration * time.Second)) |
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.
Now that this is a duration we don't want to multiple it
Correct. I'd recommend restructuring the loop a bit. Meaning don't set the deadline before the loop, and then again at the end of it. Just do something like:
|
When testing I receive:
I'm just connecting with |
What "read_timeout" value you've got in config file and how long it take to receive this message? |
Yeah this is on the actual timeout. I think we shouldn't log anything on timeout, or it should be debug level. |
How can I log it at debug level? Accumulator have only AddError method. I see three options:
|
Go with #3 for now. |
Merged as f5a8415 |
Add TCP timeout support to socket_listener
Required for all PRs: