In some scenarios such as high database load, demanding users, crazy maps and so on, responses takes too long to be delivered. Depending on the request (tile format, dataview aggregation, etc..) we need to implement a fallback to indicate properly that a timeout in database happened or Mapnik couldn't render the tile in time before the timeout fires.
[x] Research to know how to respond to the client (carto.js) a timeout happened for interactive tiles and vector formats:
Custom header in the response.
Respond with 200 (OK) and an asset for both interactive and vector formats.
[x] Asset for .grid.json
[ ] Asset for .mvt
Respond with 429 (Too Many Requests) if we can tune leaflet and google in order to support this kind of scenarios.
[x] Be able to pass to tilelive-mapnik a custom timeout (in ms).
[x] Be able to pass to tilelive-bridge a custom timeout (in ms).
Note: Unfortunately we cannot stop programatically queries that mapnik runs against the database. We hacked tilelive-mapnik in order to not wait for mapnik when a tile is requested and the timeout fires. At the end, the database is still processing the query.
2. Dataview service
[x] Catch timeout errors from database and respond:
429 and error message: {"error":["timeout: you are over the limits, please contact ..."]}
3. Attributes service
[x] Catch timeout errors from database and respond with 429 and error message: {"error":["timeout: you are over the limits, please contact ..."]}
4. Static maps service
[x] Catch timeout errors from database and respond with 429 and error message: {"error":["timeout: you are over the limits, please contact ..."]}
Chose a header to add in the response when the fallback for timeout errors is enabled, e.g: X-Timeout-Error or X-User-Over-Limits, suggestions??
Decide which http-error code fits better into our need. 429 Too many request is currently used but pretty straightforward to change if we pick another code out.
Context
In some scenarios such as high database load, demanding users, crazy maps and so on, responses takes too long to be delivered. Depending on the request (tile format, dataview aggregation, etc..) we need to implement a fallback to indicate properly that a timeout in database happened or Mapnik couldn't render the tile in time before the timeout fires.
Things to do
1. Tile service
Asset for.grid.json
Asset for.mvt
tilelive-mapnik
a custom timeout (in ms).tilelive-bridge
a custom timeout (in ms).Note: Unfortunately we cannot stop programatically queries that mapnik runs against the database. We hacked
tilelive-mapnik
in order to not wait for mapnik when a tile is requested and the timeout fires. At the end, the database is still processing the query.2. Dataview service
{"error":["timeout: you are over the limits, please contact ..."]}
3. Attributes service
{"error":["timeout: you are over the limits, please contact ..."]}
4. Static maps service
{"error":["timeout: you are over the limits, please contact ..."]}
cc/ @rochoa @jorgesancha