Repository navigation
thread-per-core: provider-key TLS clients still use a process-wide pool #908
Description
Raised by review on #891; split out as the known scope cut it was.
In thread-per-core mode the standard dispatch path uses a per-worker client (worker_client()), but a provider key with a tls override resolves through the process-wide PK_CLIENTS cache (crates/aisix-gateway/src/upstream_tls.rs, client_for_provider_key). Requests using such keys share one upstream pool across workers, so their upstream responses can land on a foreign thread and pay the cross-thread wakeup this mode exists to remove. Correctness is unaffected; custom-TLS keys just do not get the locality win.
Why it shipped this way: a per-worker x per-TLS-config client matrix multiplies connection pools (N workers x M configs), and custom-TLS provider keys are the rare path. If this gets picked up: a worker-local cache keyed by ProviderKeyTls for tpc-* threads with the shared cache kept for everything else, plus a bound or eviction so the matrix cannot grow unbounded.
Activity
coderabbitai commentedon Aug 7, 2026
🔗 Related PRs
#808 - fix(upstream): name the real transport fault and bound the connection layer [merged]
#825 - feat(auth): inbound OIDC/JWT authentication — trust providers + jwt_subject key binding [merged]
#835 - feat(headers): request-context variables in default_headers + client-header forwarding allowlist [merged]
#891 - feat(proxy): serve from thread-per-core workers with per-worker upstream pools [open]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!