Open uhthomas opened 1 year ago
That 45 seconds is not an overall timeout...that means all connections are being used and nothing has freed up in 45 seconds. Your network is running incredibly slow given how small mod files are. Set DEBUG
to "true" to inspect the progress of each file download. Of if you're still stuck, post those debug logs here.
To be fair, the network was running pretty slow. I did some tinkering and the network came back to a reasonable speed and succeeded as expected. I would suggest that slow networks shouldn't block the deployment of this software, though it doesn't seem many people have this problem.
I would suggest that slow networks shouldn't block the deployment of this software
I don't understand the suggestion. It needs to download the mods somehow, so...how would it magically proceed without the mods being downloaded and/or a sufficient network to download them? There's always the options to pre-download mods rather than using the AUTO_CURSEFORGE
automation.
Well, mods were downloading, just slowly. Given enough time it would have worked. Though, I understand if it's not something the project is interested in supporting given most networks should be faster than 1mbps.
I'm still confused about what you're thinking can be solved within the scope of AUTO_CURSEFORGE mechanism that I didn't already mention. It seems like network performance is an important facet of a server in general, so there has to be some kind of baseline assumption about the network quality.
I'm open to ideas.
An internet connection and a local network connection will have very different qualities. In my specific scenario, my ISP is taking their leisurely time to actually install a fibre connection and as such our internet connection is currently a 5G hotspot. The connection is mostly okay, sometimes less so. The local network however is 20Gbe, where we play on the server.
Again, I'm not sure if there's really any action to be taken here. It would be nice if the network client in mc-image-helper were more tolerant of slow internet connections, but I imagine that this issue will be less relevant as general connectivity continues to improve globally.
My main confusion was that nothing had stalled. Maybe 50~ of the mods had downloaded, and more mods would continue to be downloaded every time the kubelet restarted the pod. So, it seemed unnecessary to stop this process that would have eventually succeeded, even if not quickly.
Sorry, I later realized that playing on LAN would be a case where internet network performance cannot be assumed.
I'll do some research about gracefully blocking on slow connections with the networking library I'm using there in the helper.
pendingAcquireTimeout
from connection pool section seems to have a possible value of -1 which perhaps means infinite blocking. Need to expose that as an option in SharedFetchArgs
Describe the problem
I'm trying to run an 'All The Mods 8' server, but it keeps timing out whilst downloading assets. Every time the container restarts, it downloads just a few more mods before eventually timing out. It looks like the overall timeout is 45s, which is pretty low imo. Is there anyway to increase this? I don't see anything in the documentation.
Container definition
https://github.com/uhthomas/automata/blob/294172e7fc94f980a90ed97072a681983e935f23/k8s/unwind/minecraft/cf_atm8/stateful_set_list.cue#L34-L68
Container logs
See above.