[ruby-core:65620] [ruby-trunk - Bug #10367] [Rejected] Net::HTTP read_timeout value behaves unexpectedly.

Issue #10367 has been updated by Yui NARUSE.

Status changed from Open to Rejected

John Thomas wrote:
> 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.

You may know read_timeout is related to Socket#read_timeout.
Therefore your expectation is wrong.

> 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.
> 
> 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.

What you expect is Timeout.timeout(3){ ... }

----------------------------------------
Bug #10367: Net::HTTP read_timeout value behaves unexpectedly.
https://bugs.ruby-lang.org/issues/10367#change-49357

* Author: John Thomas
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: lib
* Target version: current: 2.2.0
* ruby -v: ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
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.

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.

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.


---Files--------------------------------
read_timeout.bug (1.99 KB)


-- 
https://bugs.ruby-lang.org/