You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit dd75645
Browse filesBrowse the repository at this point in the historyBrowse files
feat(grpc-gcp): prime scaled channels before publish (#14232)
With dynamic scaling enabled, a freshly built channel was published to
the pool the moment its delegate was constructed. Its first real RPCs
then paid for connection establishment, TLS, and any service-side
warm-up, so every scale-up event injected a latency spike into live
traffic right when the pool was already under load.
**Change**
- **Optional channel primer.** New `GcpChannelPrimer` hook
(`setChannelPrimer`) issues a cheap end-to-end RPC on each newly built
scale-up channel before it is published; for Cloud Spanner this can be a
`SELECT 1`. Channels in a scale-up batch are primed concurrently and
each one is published as soon as its own prime succeeds, so one slow
channel never holds back the rest. A `null` primer (the default) keeps
the existing publish-on-build path. Only dynamic scale-up channels are
primed; the initial pool is not.
- **Bounded attempts.** Each attempt is bounded by `channelPrimeTimeout`
(default 10s) and retried up to `channelPrimeMaxAttempts` (default 3)
with exponential backoff (100ms doubling, capped at 5s). The timeout
covers the whole attempt, including the synchronous `prime()` call. A
primer still blocked inside `prime()` at the timeout fails the channel
without a retry, since nothing can stop that call; primer invocations
run on a dedicated executor so a blocked primer cannot starve the shared
scheduler that drives scale-up, draining, and timeouts. Exhausted or
timed-out channels are closed and counted in the new
`scale_up_prime_failures` metric.
- **Scale-up accounting.** Channels still priming count toward both the
pool size cap and the desired size, so a second scale-up during a slow
prime batch cannot rebuild the same shortfall or construct delegates
past `maxSize`. A prime abandoned because its call never returned keeps
its slot until the call does, so a stuck primer can pin at most
`maxSize` slots rather than one thread per scale-up event.
- **Lifecycle.** Unpublished priming channels are never visible to
pickers; shutdown cancels every pending prime and closes its delegate.
Per-RPC pick and stream-accounting paths are unchanged, with no new
hot-path allocations.
- **Configuration.** `setChannelPrimeTimeout` rejects negative or
non-nanosecond-representable durations (zero uses the default);
`setChannelPrimeMaxAttempts` rejects negatives (zero uses the default).
0 commit comments