-
Notifications
You must be signed in to change notification settings - Fork 1
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
Map fetching URL exceptions need better handling #113
Comments
Similar issues are all through D-rats where it it was handling broad exceptions instead of specific exceptions. In the jobs I have worked at, it is considered bad practice to have either "except: or except Exception:" as it indicates that a module has not been properly tested, and that practice can make a programming bug harder to find. As I do not yet have a unit test suite that simulates all code paths, I need these type of reports to to help fix all the exception handling. |
This is actually two issues and the PR 114 only addresses one of them. The other problem is a bit harder to fix, that is that there were so many map url requests in progress that were failing that the program ran out of resources. The code in d-rats launches a new thread for each tile fetch request, with no queuing done to limit the number that can be in flight. This would need to be re-written to have a queue of tile requests so that only a limited number of parallel threads would be active at a time. Then feature creep sets in to optimize the queue to remove duplicate fetch requests or fetch requests that are not needed any more because the zoom level changed. |
Opened a new ticket for the potential throttling of map requests. |
Some Map URL fetches exceptions seen.
The text was updated successfully, but these errors were encountered: