OSGeo
Avoid failing on HTTP responses that are retryable for VSICurlHandle::ReadMultiRange
Feature description
GDAL supports configuration options GDAL_HTTP_MAX_RETRY and GDAL_HTTP_RETRY_CODES to deal with intermittent issues.
The VSICurlHandle::ReadMultiRange code path (gdal/port/cpl_vsil_curl.cpp#L2626) does not have retry logic. Given that the code path does multiple requests in parallel it is easy to get retryable response codes like 429 but currently they seem to fail.
Additional context
Possibly impact can be reduced by leveraging GDAL_HTTP_MERGE_CONSECUTIVE_RANGES=YES or limiting connections using GDAL_HTTP_MAX_TOTAL_CONNECTIONS (for gdal >=3.11) but intermittent issues can also come from outside user control and retry would help to limit impact.
Does your issue have anything common with https://github.com/OSGeo/gdal/issues/12426?
Does you issue have anything common with #12426?
closely related, but different code paths . #12426 is about AdviseRead() (asynchronous requests), wheres this one is about ReadMultiRange() (synchronous requests)
is it possible to avoid this code path (no retry logic in readmultirange) by specifying GDAL_HTTP_MULTIRANGE=SERIAL ?
is it possible to avoid this code path (no retry logic in readmultirange) by specifying
GDAL_HTTP_MULTIRANGE=SERIAL?
yes