Currently a cronjob more often than once every hour leads to a 429 http response code (too many requests).
No documentation found yet which explains the limit leading to a 429 return code.
Another issue is that probably the communication within the script regarding the last send request (which is currently done using the database) seems not to work smoothly. This might be because of a delay in the database, so that written timestamps will not be returned by the select statement immediately (race condition?). This is not tested. I only had the feeling that multiple download requests had been sent out within the 30 minutes - which should not be the case.
However, maybe it is better to read the last timestamp at the beginning in a global variable and to update the global variable while the script is running.
Another thing is, that currently two requests are sent for one download request. The first request determines if the tile is online. If not then a download request is sent if the last download request is not younger than 30 minutes. This multiple requests could also be leading to the 429 return code. Maybe this could be optimized as well.
Currently a cronjob more often than once every hour leads to a 429 http response code (too many requests).
No documentation found yet which explains the limit leading to a 429 return code.
Another issue is that probably the communication within the script regarding the last send request (which is currently done using the database) seems not to work smoothly. This might be because of a delay in the database, so that written timestamps will not be returned by the select statement immediately (race condition?). This is not tested. I only had the feeling that multiple download requests had been sent out within the 30 minutes - which should not be the case.
However, maybe it is better to read the last timestamp at the beginning in a global variable and to update the global variable while the script is running.
Another thing is, that currently two requests are sent for one download request. The first request determines if the tile is online. If not then a download request is sent if the last download request is not younger than 30 minutes. This multiple requests could also be leading to the 429 return code. Maybe this could be optimized as well.