Modify ↓
Opened 5 years ago
Last modified 5 years ago
#19934 new enhancement
Smarter retry mechanism to avoid thousands repeated requests in case of errors 500 from imagery servers
| Reported by: | Owned by: | team | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core imagery | Version: | |
| Keywords: | error retry | Cc: |
Description
An imagery server had temporary issues and sent errors 500 (internal error).
When aerial images was requested, JOSM repeated thousand times the request with logs, doing a great activity of my system CPU.
It should have a limit of the interval of time between requests in errors when they was repeated.
For example : after ten errors, the interval of request should be of 10 seconds, after 100 errors, 30 seconds, after 200 errors, 5 minutes.
Attachments (0)
Change History (3)
comment:1 by , 5 years ago
| Component: | Core → Core imagery |
|---|
comment:2 by , 5 years ago
| Keywords: | error retry added |
|---|---|
| Summary: | Errors 500 on imagery servers makes thousands repeated requests of JOSM → Smarter retry mechanism to avoid thousands repeated requests in case of errors 500 from imagery servers |
| Type: | defect → enhancement |
comment:3 by , 5 years ago
Note:
See TracTickets
for help on using tickets.
I usually use a factor of 1.5 for retry with an upper limit. E.g in seconds
0 1 2 3 5 8 12 18 27 ... 300 (rounded up and special for 0 to 1). This is extremely fast for short problems, but gets slow soon for larger outages.