Closed antoninbas closed 1 month ago
Just want to double check, I think the client will close the connection as it gets error and reconnect it when the connection is closed by server during sending the data?
Just want to double check, I think the client will close the connection as it gets error and reconnect it when the connection is closed by server during sending the data?
If you are referring to what happens (after merging this patch) when the server closes the connection then: after at most 10s, the code will detect that the connection is closed, closeConnToCollector
will be called (internally); the next time there is data to be sent, there will be an error (trying to send on closed connection), and the client will try to reconnect.
This is a partial reversal of d072ed8. It turns out that the check can actually be useful as it can detect that the collector ("server" side) has closed its side of the connection, and this can be used as a signal to close our side of the connection as well. This can happen when a process using our collector implementation is closed, but no TCP RST is received when sendign a data set (in particular, this can happen when running in K8s and using a virtual IP to connect to the collector). This check can detect the issue much faster than relying on a keep-alive timeout. Furthermore, a client of this library could end up blocking if the connection has not timed out yet and the send buffer is full.