[ruby-core:96028] [Ruby master Feature#16381] Accept resolv_timeout in Net::HTTP
From:
XrXr@...
Date:
2019-11-29 16:38:36 UTC
List:
ruby-core #96028
Issue #16381 has been updated by alanwu (Alan Wu). On second thought, I'm not thrilled about adding a new config option like t= his. I think name resolution is logically part of opening a socket, so I would e= xpect a `Net::OpenTimeout` if name resolution takes longer than the specifi= ed amount. On the other hand, it seems that effectively cancelling name resolution is = hard to do currently, especially on systems that don't have `getaddrinfo_a`. ---------------------------------------- Feature #16381: Accept resolv_timeout in Net::HTTP https://bugs.ruby-lang.org/issues/16381#change-82880 * Author: kirs (Kir Shatrov) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- This is a follow-up to https://bugs.ruby-lang.org/issues/15553 and a succes= sor of https://github.com/ruby/ruby/pull/1806 (the credit to Carl H=F6rberg= ). Unlike https://github.com/ruby/ruby/pull/1806, this patch introduces a sepa= rate `resolv_timeout` Net::HTTP would pass to `Socket.tcp`. The idea to have it as a separate value (vs reusing open_timeout) was sugge= sted by Alan Wu. It's helpful in case specifies open_timeout: 1, DNS resolv= takes 0.9s and opening TCP connection takes 0.9s, and the total wait time = is 1.8s even though the allowed timeout was 1s. This patch not only makes DNS timeout customizable, but also fixes a bug wh= en wrapping `TCPSocket.open` into whatever seconds `Timeout.timeout` would = still take 10 seconds because of the nature of blocking resolv operation on= many systems (here's a gist to reproduce on Linux: https://gist.github.com= /kirs/5f711099b23ddae7a87ebb082ce43f59). This problem is not hypothetical, it's something we've been seeing in produ= ction fairly often: even with open/read timeouts on Net::HTTP as low as a s= econd, the Ruby process would still be blocked for 10s (system's resolv tim= eout) in case of DNS issues. And on web servers with blocking IO (e.g. Unic= orn) this would cause the loss of capacity. ---Files-------------------------------- resolv.patch (2.9 KB) -- = https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=3Dunsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>