request timeout management

[Álvaro Monteiro]

Hi!!!

When the webserver i try to connect is down it takes a long time to
get a timeout response.
Is it possible to decrease this time? Does Restkit try several times
before warning me that there was a timeout? -> hence the long time it
takes..

Regards,

Alvaro Monteiro

[David Carrico]

Just a guess but in the RestKit source, you could change:

static const NSTimeInterval kTimeout = 300.0;

to something shorter (in seconds), then rebuild the kit...

I'm not sure if that is the correct timeout though.

2011/4/2 Álvaro Monteiro <alvarosil...@gmail.com>

[Blake Watters]

That timeout isn't actually connected -- I've thrown a TODO item into Pivotal to implement a configurable timeout. 

		Blake Watters Two Toasters | CTO bl...@twotoasters.com (919) 926-8537

[Álvaro Monteiro]

Thank you Blake!

Just one more thing: Does Restkit try several times

before warning me that there was a timeout?

If so, i think it's safe to assume that if there is a timeout it happens because something went really wrong instead of some temporary loss of connectivity.

Is this true?

[Gregory Combs]

Ironic, I just ran into this today. Hoping I can find the spot to hardcode a more reasonable timeout in the interim, I'm hoping to ship early this week.

[Álvaro Monteiro]

If you can please share you solution. thks!!!

[Blake Watters]

Greg -

If you want to implement a patch for this I'll merge it. Here's what you should do:

- Put a timeout property on RKRequest with a reasonable default interval

- At send time, fire an NSTimer that is set to go off on the interval

- When the NSURLConnection starts loading data (didReceiveData: or something), invalidate the timer

- When the timer goes off, cancel the request and either invoke didFailWithError: or we can add a new didTimeout: methose (I think I already did this on background requests branch, which needs to be merged when I get a minute)

- Blake

On Mon, Apr 4, 2011 at 6:57 PM, Gregory Combs <gco...@gmail.com> wrote:

Ironic, I just ran into this today. Hoping I can find the spot to hardcode a more reasonable timeout in the interim, I'm hoping to ship early this week.

[Blake Watters]

BTW my research shows that NSURLConnection's default timeout is insanely high to allow the network time to connect and you can't override it easily, so you need to use a timer based solution as outlined

[Álvaro Monteiro]

ok thks guys.

[peetonn]

i think not less important thing here is, in case invoking "didTimeout" - to remove timed out request from a queue. otherwise queue will contain these requests, won't it?

[Sendhil P]

Did this ever make it in as a patch?

[Blake Watters]

I have not merged such support

[Kamil]

Ok, so what does the [someQueue setRequestTimeout:3] do in that case? Because I see no change. Timeout always defaults to Apple's 60 seconds. Is this also not connected?

[Brian Morton]

I've forked and implemented this as prescribed in this thread. I've
opened a pull request (https://github.com/RestKit/RestKit/pull/491)
and hopefully I'm on the right track. Like I mention in the pull
request, I'm dying to spec what I've added, but I'm a bit lost as to
where to start. Any pointers that could push me in the right
direction would be greatly appreciated.

On Nov 9 2011, 7:18 pm, Blake Watters <blakewatt...@gmail.com> wrote:

[Blake Watters]

Brian -

This patch looks very nice. I've added some comments on the pull request that should help you knock out some unit test coverage for the patch.

--
To stay sane & productive, I don't live in e-mail. If you need to reach me quickly, try this link: https://awayfind.com/blakewatters

[Brian Morton]

I've added tests for making sure the RKRequest can timeout when the
server doesn't respond before the timeoutInterval as well as
confirming that an RKClient passes through its timeoutInterval to a
request that it creates. I've also added a route in the sinatra spec
server for triggering the timeout.

I was seeing some issues with the ruby process holding too long and
triggering the response loader timeout on the tests following it, but
i've shortened the times a bit and haven't been able to trigger that
issue again, so it should be good to go!

Thanks for the helpful hints and let me know if i missed anything.

-b

On Jan 9, 5:35 pm, Blake Watters <blakewatt...@gmail.com> wrote:
> Brian -
>
> This patch looks very nice. I've added some comments on the pull request
> that should help you knock out some unit test coverage for the patch.
>