Project

General

Profile

Bug #10367

Net::HTTP read_timeout value behaves unexpectedly.

Added by thomas07vt (John Thomas) about 5 years ago. Updated about 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
ruby -v:
ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-linux]
[ruby-core:65614]

Description

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) read_timeout.bug Script to reproduce with logging. thomas07vt (John Thomas), 10/11/2014 07:45 AM

History

Updated by thomas07vt (John Thomas) about 5 years ago

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

Updated by naruse (Yui NARUSE) about 5 years ago

  • 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){ ... }

Also available in: Atom PDF