Bug #10367: Net::HTTP read_timeout value behaves unexpectedly.

• Status: Rejected
• Assignee: -
• Target version: 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

[thomas07vt (John Thomas)]

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.

[thomas07vt (John Thomas)]

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

[naruse (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){ ... }