#1275 Timeout after multiple requests with curl_easy_reset

[lietus]

Running on iPad, iOS 6.0.1, libcurl/7.29.0 OpenSSL/1.0.1e zlib/1.2.5.

I'm executing multiple HTTP POST requests with same content size - uploading big file in chunks.
After few requests are completed, one request gets stuck until timeout happens.
Which request will timeout is always more or less the same - it depends on request size being sent.

For example, uploading:
4 MB requests will always result in 2th requests stuck;
2 MB requests - 4th requests stuck;
100000 B requests - 58th requests stuck;
10000 B requests - ~316th requests stuck (+-);

However, I noticed that if I call curl_easy_init instead of curl_easy_reset, this problem goes away. What doesn't curl_easy_reset do for this to happen?

Also, after timeout happens, I call curl_easy_reset and setopt all values needed, that also fixes problem for another few requests (same pattern applies).
curl_easy_init cannot applied here because it would slow down other requests that come though this code.

Thanks,
Vincas

[Daniel Stenberg]

You say it timeouts but in the description you say they "get stuck". Can you clarify exactly what happens?

I assume you're using the curl_easy_perform() call to do the transfers?

Also, isn't it so that in the case of easy_reset() you re-use the same connection A LOT in a way you don't if you easy_init all the time and thus you may just see problems with a long-standing persistent connection?

[lietus]

Hi,

I meant timeouts. But they come because of CURLOPT_LOW_SPEED_LIMIT & CURLOPT_LOW_SPEED_TIME (that are set to 1byte/20seconds). That means "stucked" requests send some of their bytes to server and then stop sending them until low transfer speed condition occurs.

And yes, intention is to reuse existing connections. They use SSL so reusing sounds like a good idea to me.

Is there a limit for how much connection could be reused?
My tests showed that "stuck" pattern is dependent only on request size, but not on time. That means same pattern applies if upload speed is reduced dramatically, thus more time same connection is used.

Thanks,
Vincas

[lietus]

And yes, I'm using curl_easy_perform()

[Daniel Stenberg]

Neither TCP nor SSL have any time nor data limit in general so there's no limit in how much they can be re-used, for how long they can be used or how much data that can be sent or received.

Your particular server or network environment may however and that's not something I can tell.

Connection re-use in the way you do it is a VERY common use case with libcurl and is done by virtually every single libcurl application and your observation is not something I hear from others.

Are you communicating to several different servers or just one? Do you see the same problems with all of the servers?

[Daniel Stenberg]

I don't see enough proof that this truly is a libcurl bug.

[lietus]

What could be workflow to test if that is curl issue? I could run some tests with my setup

[Daniel Stenberg]

I really can't tell. It looks like you have a problem with long-running connections but there's nothing in libcurl that cares about age or how much data that has been sent so I really cannot understand how this can be a libcurl issue.

To tell if this is a libcurl issue, you probably need to show that you can do this kind of long-living connections without libcurl just fine and that you only see these problems when using libcurl.