Skip to content
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

Feature request: better handling of "too many connections"-errors #50

Open
Tensai75 opened this issue Aug 23, 2018 · 1 comment
Open

Comments

@Tensai75
Copy link

Hi, it's me again.

I did several tests with nyuu, forcing a lot of "too many connections"-errors by setting the option -n to a higher amount of connections than my host allows. During theses tests nyuu always aborted after X errors where X equals the amount of connections set with option -n. And this even if I did set the --skip-errors all option.
I think this is a very strange behavior because "too many connections"-errors aren't that fatal. As you mentioned in my other issue (#49) the connection accounting by the hosts isn't always reliable and "too many connections"-errors can happen from time to time and I don't see a reason to abort the whole upload process only because of "too many connections"-errors, especially when there are still other connections available and used for uploading.
I think it would therefore be better to handle "too many connections"-errors differently. My suggestion would be to always retry but with a higher delay. In this way the articles blocked by the "too many connections"-errors will be uploaded eventually in the end.
If possible, the handling of the "too many connections"-errors should be controllable via additional option parameters.

Thanks and kind regards, Tensai

@animetosho
Copy link
Owner

The --skip-errors all option (or just --skip-errors connect-fail) should cause Nyuu to continue regardless of such connection failures, so that's weird that it isn't doing that for you. Can you post some of the log, in particular, the last few messages?

always retry but with a higher delay

These are actually configurable via the --connect-retries and --reconnect-delay options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants