HttpClient sends every request through one cpr::ConnectionPool (http_client.cc#L158), which wraps a libcurl share handle with CURL_LOCK_DATA_CONNECT. libcurl does not support sharing connections between threads, so when two requests overlap, the process can crash inside libcurl.
A RestCatalog sends its requests through one HttpClient, so they can overlap even if the application only uses the catalog from one thread:
Applications that share a catalog across threads hit it directly (see #21). We found it in a DuckDB extension's concurrency test.
The shared pool came in with apache#530, which replaced a mutex-guarded cpr::Session. #19 gives each in-flight request its own pool. Reproduction in the first comment.
HttpClientsends every request through onecpr::ConnectionPool(http_client.cc#L158), which wraps a libcurl share handle withCURL_LOCK_DATA_CONNECT. libcurl does not support sharing connections between threads, so when two requests overlap, the process can crash inside libcurl.A
RestCatalogsends its requests through oneHttpClient, so they can overlap even if the application only uses the catalog from one thread:RestCatalog::Make, metrics reports are posted from its threads (rest_metrics_reporter.cc#L74);TokenRefreshScheduler's thread (auth_session_internal.h#L205).Applications that share a catalog across threads hit it directly (see #21). We found it in a DuckDB extension's concurrency test.
The shared pool came in with apache#530, which replaced a mutex-guarded
cpr::Session. #19 gives each in-flight request its own pool. Reproduction in the first comment.