Net::HTTP Timeout

ruby-talk
1

Yes, I have read the previous thread (http://www.ruby-forum.com/topic/105212), but I have one small question:

Would it be so terribly bad to change it from:
>> def rbuf_fill
>> timeout(@read_timeout) {
>> @rbuf << @io.sysread(1024)
>> }
>> end

to:

>> def rbuf_fill
>> Thread.new {
>> @rbuf << @io.sysread(1024)
>> }
>> end

? Would the uncapturable thread cause me a problem? Timeout runs it in another thread anyways, so this is just removing the timeout aspect.

-------------------------------------------------------|
~ Ari
seydar: it's like a crazy love triangle of Kernel commands and C code

2

This is a terrible idea. Starting in another thread causes rbuf_fill to return immediately instead of waiting to fill the buffer. The use of timeout causes it to wait a while trying, and then abort if it fails. Using a thread without a timeout will completely monkey with things.

Is there some reason as to why you want to do this? What are you trying to accomplish?

-Bryan

···

On Jan 1, 2008, at 10:49 AM, thefed wrote:

Yes, I have read the previous thread (http://www.ruby-forum.com/topic/105212\), but I have one small question:

Would it be so terribly bad to change it from:
>> def rbuf_fill
>> timeout(@read_timeout) {
>> @rbuf << @io.sysread(1024)
>> }
>> end

to:

>> def rbuf_fill
>> Thread.new {
>> @rbuf << @io.sysread(1024)
>> }
>> end

? Would the uncapturable thread cause me a problem? Timeout runs it in another thread anyways, so this is just removing the timeout aspect.

-------------------------------------------------------|
~ Ari
seydar: it's like a crazy love triangle of Kernel commands and C code

3

When I'm using ruby to download large files, everynow and then the server doesn't respond for over 60 seconds, and my program crashes with a timeout error.

···

On Jan 1, 2008, at 10:34 PM, Bryan Duxbury wrote:

This is a terrible idea. Starting in another thread causes rbuf_fill to return immediately instead of waiting to fill the buffer. The use of timeout causes it to wait a while trying, and then abort if it fails. Using a thread without a timeout will completely monkey with things.

Is there some reason as to why you want to do this? What are you trying to accomplish?

4

It seems to me that your program, or whatever is using Net::HTTP should
handle the timeout better, rather than crashing. You can always wrap
the call in something that rescues the timeout error and retries
(perhaps after printing out a warning), or you could ask the user what
to do. Not timing out at all isn't the best approach.

Ben

···

On Wednesday 02 January 2008, thefed wrote:

> Is there some reason as to why you want to do this? What are you
> trying to accomplish?
>

When I'm using ruby to download large files, everynow and then the
server doesn't respond for over 60 seconds, and my program crashes
with a timeout error.

5

Ben Giddings wrote:

···

On Wednesday 02 January 2008, thefed wrote:

> Is there some reason as to why you want to do this? What are you
> trying to accomplish?
>

When I'm using ruby to download large files, everynow and then the
server doesn't respond for over 60 seconds, and my program crashes
with a timeout error.

It seems to me that your program, or whatever is using Net::HTTP should
handle the timeout better, rather than crashing. You can always wrap
the call in something that rescues the timeout error and retries
(perhaps after printing out a warning), or you could ask the user what
to do. Not timing out at all isn't the best approach.

Ben

The crash is caused by the default behavior of timeouts (which is what
Net::HTTP uses). By default timeouts throw an InterruptException which
kills the current thread. You can get a simple fix for this with the
http_configuration gem/plugin
(http://agilewebdevelopment.com/plugins/http_configuration\).
--
Posted via http://www.ruby-forum.com/\.