Open viniarck opened 1 month ago
It's expected that if increasing the api_concurrency_limit this is supposed to go away,
With api_concurrency_limit
and api
thread pool as 512 it didn't result in issues.
The default value on kytos.conf
as of July 25th is 160.
It should probably mark it for a next deployment to try to recover from this failure (this isn't a consistency check, just part of the rest of error handling)
This needs to be assessed, discussed, and see if it'd work reliably, and or think about anything that can still be done.
It's probably worth considering retries with tenacity and pacing the method that sends requests too
Scenario:
backup_path
which is really problematic since it would mean full outage, and it would only recover in a next network link up event. See below one example of a problematic EVC that didn't converge.It's expected that if increasing the
api_concurrency_limit
this is supposed to go away, I'll cover this test to confirm that it'll behave as expected. However, this is also already a sign that the default value isn't suitable to handle 300+ EVCs, so this needs to be better documented. Also, finally mef_eline should handle this error more completely, logging the error is the minimum expected in this case, but not doing anything after that it's problematic. It should probably mark it for a next deployment to try to recover from this failure (this isn't a consistency check, just part of the rest of error handling)