https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112014-10-11T07:49:10ZRuby Issue Tracking SystemRuby master - Bug #10367: Net::HTTP read_timeout value behaves unexpectedly.https://bugs.ruby-lang.org/issues/10367?journal_id=493522014-10-11T07:49:10Zthomas07vt (John Thomas)thomas07vt@gmail.com
<ul></ul><p>This should be assigned to NARUSE, Yui (naruse) it looks like.</p> Ruby master - Bug #10367: Net::HTTP read_timeout value behaves unexpectedly.https://bugs.ruby-lang.org/issues/10367?journal_id=493572014-10-11T18:09:04Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>John Thomas wrote:</p>
<blockquote>
<p>I would think that the expected behavior of the Net::HTTP.new().read_timeout property be that if that timeout was hit during a request, a Net::ReadTimeout exception would be thrown, and the request would be killed. Currently, however, when you set the read_timeout property and a request hits that timeout, the exception is caught in the 'transport_request' method and is retried. This retry is controlled by a hardcoded counter, and will only retry once (but always once). Is this the expected behavor? I would think that either the request not be retried for this Net::ReadTimeout expection, or the number of reties be settable.</p>
</blockquote>
<p>You may know read_timeout is related to Socket#read_timeout.<br>
Therefore your expectation is wrong.</p>
<blockquote>
<p>The problem I have with this behaviour is that I would like the ability to know roughly when the max return time for a call will be (successful or unsuccessful). The current behavior will take twice a long if the server is not responding in the read_timeout time.</p>
<p>I would guess the solution for this is just to remove the Net::ReadTimeout exception from the "rescue Net::ReadTimeout, ..." block in the 'transport_request' method. This would skip the retry.</p>
</blockquote>
<p>What you expect is Timeout.timeout(3){ ... }</p>