Repository navigation
Connections timeout in a second聽#128
Description
timeouts (like in a sec) are prevalent despite deadlines being set to zero (which should actually mean "infinity" per net.Conn godoc but ... 馃し).
Line 226 in 03ab20e
02-07 19:00:03.389 7531 9141 E GoLog : retrier.go:336: E retrier: read# 1: [100.65.177.238:47752<=157.240.252.17:443] 0; err? read tcp 100.65.177.238:47752->157.240.252.17:443: i/o timeout
02-07 19:00:03.595 7531 7853 E GoLog : retrier.go:336: E retrier: read# 2: [100.65.177.238:47760<=157.240.252.17:443] 0; err? read tcp 100.65.177.238:47760->157.240.252.17:443: i/o timeout
02-07 19:00:03.808 7531 7853 E GoLog : retrier.go:336: E retrier: read# 3: [100.65.177.238:47762<=157.240.252.17:443] 0; err? read tcp 100.65.177.238:47762->157.240.252.17:443: i/o timeout
02-07 19:00:04.324
Happens in both non-loopback and loopback modes. No clue why or what triggers it, but once it is triggered, it happens non-stop for ALL conns.
Activity
dialers/retrier: debug log conn deadlines
tcp,udp: fast path for core.Pipe if no idle timeouts set
tcp,udp: impl user-set idle timeouts
ignoramous commentedon Feb 7, 2025
net.Conn.SetDeadlines have to be called on each read and write if the intention is to mimic "idle timeout". Otherwise, the network poller would simply manifest an "i/o timeout" on exceeded deadlines.This is unfortunate as decorating a
*net.TCPConnto extend deadlines on reads/writes means losing out onio.Copyoptimization usingsendfilefor zero-copy ops (ref).