When mTLS is configured or dynamically updated, the SDK creates and mounts new HTTP adapters/transports but leaves the old ones hanging. While PR #17689 addressed this for the requests transport, the leak still exists in two other places:
-
urllib3 transport (google/auth/transport/urllib3.py)
In configure_mtls_channel, self.http = new_http replaces the old PoolManager. We need to call .clear() on the old PoolManager instance before overwriting it so that the active connection pool is cleaned up.
-
Compute Engine metadata (google/auth/compute_engine/_metadata.py)
If mTLS is enabled, _metadata.py instantiates and mounts a new MdsMtlsAdapter on the session for every single request. Overwriting the mounted adapter without closing the old one leaks sockets. We should either cache and reuse the adapter or close the old one before mounting.
When mTLS is configured or dynamically updated, the SDK creates and mounts new HTTP adapters/transports but leaves the old ones hanging. While PR #17689 addressed this for the
requeststransport, the leak still exists in two other places:urllib3 transport (
google/auth/transport/urllib3.py)In
configure_mtls_channel,self.http = new_httpreplaces the old PoolManager. We need to call.clear()on the oldPoolManagerinstance before overwriting it so that the active connection pool is cleaned up.Compute Engine metadata (
google/auth/compute_engine/_metadata.py)If mTLS is enabled,
_metadata.pyinstantiates and mounts a newMdsMtlsAdapteron the session for every single request. Overwriting the mounted adapter without closing the old one leaks sockets. We should either cache and reuse the adapter or close the old one before mounting.