The http.rb library we're using supports granular timeouts for connect, write and read. For now, this just sets them all to 10 seconds. That means in principle a request could still last for 30 seconds without timing out (10s to connect, 10s to write the headers and event body, 10s to read the response headers). In practice, slowness in each phase is likely to have a different cause (e.g. connect slowness is probably the network, write/read probably shepherd hanging), so in most cases I'd expect this to time out after 10 seconds as desired.
This doesn't make the timeouts user-configurable, but it would be easy to add them to Client and plumb them through if someone asks for it.
Tested on my laptop by hardcoding api_host to localhost:9379, running nc -l 9379 and hitting Ctrl-Z to suspend it. (That leaves the socket open and its buffer accepting writes, but nothing writing responses back, which hits the read timeout.)
Consistent with https://github.com/honeycombio/libhoney-py/pull/45 and https://github.com/honeycombio/libhoney-go/pull/34, this adds a 10 second timeout to each HTTP POST.
The
http.rblibrary we're using supports granular timeouts forconnect,writeandread. For now, this just sets them all to 10 seconds. That means in principle a request could still last for 30 seconds without timing out (10s to connect, 10s to write the headers and event body, 10s to read the response headers). In practice, slowness in each phase is likely to have a different cause (e.g. connect slowness is probably the network, write/read probably shepherd hanging), so in most cases I'd expect this to time out after 10 seconds as desired.This doesn't make the timeouts user-configurable, but it would be easy to add them to
Clientand plumb them through if someone asks for it.Tested on my laptop by hardcoding
api_hosttolocalhost:9379, runningnc -l 9379and hitting Ctrl-Z to suspend it. (That leaves the socket open and its buffer accepting writes, but nothing writing responses back, which hits the read timeout.)