New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timeouts too low for some actions #165
Comments
Interesting question, thanks for raising it.. I'm a bit wary about indefinite timeouts - if the registry you're pulling from is down, you might get a hanging process. I'm not convinced that consumers of the library would do the sensible thing and create their own timeouts. Having more fine-grained timeouts with a sensible default sounds like a great improvement (if someone wants to pick that up). |
I'm currently faced with a bollard-based app that works nicely for me but timeouts on a project colleague's home computer during build (CLI The ability to remove or customize timeouts would indeed be very useful. |
You can configure it by calling I'll look into adding a method to change the timeout after instantiation, it doesn't complicated |
What a coincidence :) |
Thank you for adding setting timeout methods! But as @sjoerdsimons said, we need different timeouts for different methods, because request for a list of containers is a fast operation but download 1gb image is not. Can we reopen this issue to add this possibility? |
How do you suggest the API should change ? It would be a bit strange to add a parameter or option to each method with a timeout argument. Maybe with a macro? |
How it can be done with macro? My thoughts was an adding method to client like |
Happy to re-open this for visibility. If we can get a granular proposal for the API agreed, that might move the needle in getting it implemented. |
I can try to make a draft pr. What do you think? |
That sounds great. |
At the moment I don't understand how to do it without Docker struct redesign
|
Thanks for giving it a shot.. I thought maybe something simpler like having a function with a callback might work, but in my naive attempt it was having issues with the borrow checker. |
The problem with big sized images can be solved like this: let ci = client
.create_image(
Some(CreateImageOptions {
from_image,
..Default::default()
}),
None,
credentials,
)
.try_collect::<Vec<_>>();
tokio::time::timeout(Duration::from_secs(1), ci).await.unwrap().unwrap(); So, maybe timeouts per function are not necessary. |
The bollard API only seems to have one general timeout for all of the client actions (2 minutes by default, or user provided when using
connect_with_unix
directly).As always, timeouts are awkward (it's rougly impossible to get them right for all situations). But in this case that same timeout is used for all actions. Some you would hope are always fastish (e.g. listing running containers). However some can take a long while e.g. pulling a big image on a slow connection.
I'm unsure what a good solution is here; For now i'm working around it in client code by just setting the timeout to a day... But i guess the options roughly would be:
The text was updated successfully, but these errors were encountered: