From: thomas07vt@...
Date: 2014-10-11T07:49:11+00:00
Subject: [ruby-core:65615] [ruby-trunk - Bug #10367] Net::HTTP read_timeout value behaves unexpectedly.

Issue #10367 has been updated by John Thomas.


This should be assigned to NARUSE, Yui (naruse) it looks like.

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

* Author: John Thomas
* Status: Open
* 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/