S3: question about RequestTimeout

[mikewang2016]

When internet network is slow, it's quite common to see error message below during data upload.

RequestTimeout Message: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed

Sometimes, retry can work, but for most of the time, it does not work even after retries several times.

What can cause this problem? And what's "timeout period"?

[JonathanHenson]

See the ClientConfiguration, there are two parameters you may be interested in. RequestTimeout and ConnectTimeout. They both default to 3 seconds. You probably want to increase the request timeout.

[mikewang2016]

Yes, I have set ConnectTimeout=10s, RequestTimeout=200s, but can still see this error message.

I can see that a request may hang for 40s, and then report this error.

[mikewang2016]

By the way, I am using multiparts upload, every part is about 10MB.

[mikewang2016]

more information:

After tested over several networks, I found that this problem only occurs in a network which has packet lost.

It has nothing to do with network latency: a high latency network can work perfect as long as there is no packet lost.

If there are packet lost sometimes (not really always), then there is high chance this problem can occur.

BTW: I am using "Aws::StringStream" to feed "SetBody()" of "UploadPartRequest", if I get RequestTimeout exception from "UploadPart", and want to retry the upload, do I need first rewind by calling "seekg (0, is.beg)" of "Aws::StringStream"?

[mikewang2016]

Can I have an update on this query?

[JonathanHenson]

Request timeout is supposed to automatically trigger a retry using an exponential backoff strategy. The retry will automatically rewind your stream. If you manually retry, you do need to rewind the stream manually. Though, I would recommend simply injecting a retry strategy into the client configuration to do what you need it to do.

[JonathanHenson]

I just reworked the timeouts for curl implementations to behave more like a socket read timeout. You should be able to set this back to something reasonable (like 3 seconds) and everything will work as it does on windows.