You can add the timeout parameter to your upload call to override the maximum amount of time to wait for a response from Cloudinary before the connection is terminated through the SDK.
For example:
Rails:
Cloudinary::Uploader.upload('my_image.jpg', timeout:60)
PHP:
\Cloudinary.Uploader::upload('my_image.jpg', array("timeout" => 60));
IOS:
uploader upload:@"my_image.jpg"options:@{@"timeout": @"60"}]
.NET (global variable):
m_cloudinary.Api.Timeout = 60000;
Python:
uploader.upload("my_image.jpg", timeout=0.001)
UPDATE:
Node.js (v2):
cloudinary.v2.uploader.upload('my_image.jpg', {timeout:60000}, function(error,result){});
If timeouts still persist, please open a support ticket.
Comments
10 comments
Hi,
How set this limit in .NET?
Thanks
Changing the timeout on our .NET libraries is still not supported. Default value is 100000 milliseconds (=100 seconds).
As the libraries currently use the WebRequest class for HTTP client, you can dive into the code to implement this on your own. We will update here once it becomes officially supported.
UPDATE: customizing
timeoutwithin our .NET libraries is now supported as well.Hey nadav, the node.js update that you just added has an error in syntax. The {timeout:60000} is supposed to come after the callback function
Hi Navjeet, this syntax relates to the .v2 syntax, e.g.:
var cloudinary = require('cloudinary').v2;What time unit is the timeout measured in? In some examples it's 60, others 60000. I assume 60 is in seconds, but 60000 is milliseconds? Why is the unit different between different languages?
Is it possible to set a default timeout anywhere? Using Django Admin's CloudinaryField it doesn't seem like it's easy to override a timeout since we don't directly access the uploader.
Hi Richard.
There is currently no way to implement a global timeout like you say.
We do have an open request with our dev team to allow more access in CloudinaryField and the timeout is one of them.
As soon as there are any insights regarding this I would let you know.
The implementation in seconds and milliseconds is different because the languages and SDKs are different, Some of our libraries perfromed better with milliseconds implementation so we chose that.
In other cases the default was seconds so we wanted to conform to the default.
Hope that helps.
Hi Nadav,
Hi Said,
We will need more information in order to investigate this issue. Can you please share the code snippet and your cloud name and we will be able to check further. If privacy is a concern, then please feel free to open a support ticket at support@cloudinary.com.
Regards,
Aditi
Hi Aditi,
My source codes:
https://github.com/jahanalem/DatingApp/commit/dc880a46cb22b505a824b6612a67c4279e87d37d
a screenshot from the error:
https://stackoverflow.com/questions/66164246/cloudinarydotnet-stream-readtimeout-threw-an-exception-of-type-system-invalid
Regards,
Said
Hi Said,
Thanks for sharing that.
Looking at the code, the one thing that may cause timeouts from the Cloudinary side, depending on the size of the file you are uploading, is the fact you're requesting an incoming transformation based on the following line: https://github.com/jahanalem/DatingApp/commit/dc880a46cb22b505a824b6612a67c4279e87d37d#diff-56a13120aebd0d27d86b06af7efb1b1d5cec2bb5f26f0df337f061392c940cb3R36
Since you aren't passing the 'Async' parameter set to true this transformation is attempted to be run synchronously on Cloudinary which will increase the processing time and that may be the cause of the errors you're seeing.
The ` UploadAsync` method makes the upload async on the client-side meaning your code doesn't stall until it gets a response, but this doesn't control the sync vs async processing of the transformation on Cloudinary.
As a first step, may I please ask you to pass the 'Async' parameter set to true in your `ImageUploadParams` and test again?
In addition, from the error you are receiving, I suspect the timeout isn't coming from the SDK but rather coming from the line before the upload: https://github.com/jahanalem/DatingApp/commit/dc880a46cb22b505a824b6612a67c4279e87d37d#diff-56a13120aebd0d27d86b06af7efb1b1d5cec2bb5f26f0df337f061392c940cb3R32
Could you also please verify that there is data coming through on that stream?
Lastly, could you try uploading by passing the path to that file from disk rather than a stream, does that work?
Please sign in to leave a comment.