PYTHON-4440 - Add executor thread limit for pyopenssl_context

[NoahStapp]

No description provided.

[ShaneHarvey]

I think it's better to use the loop's default executor in this case. That way we don't need to create extra threads when the app uses run_in_executor in other places executor. Also, maxConnecting is not a concern here because it's enforced at a higher level.

[NoahStapp]

I think it's better to use the loop's default executor in this case. That way we don't need to create extra threads when the app uses run_in_executor in other places executor. Also, maxConnecting is not a concern here because it's enforced at a higher level.

This PR addresses the case we discussed last week where if you keep opening new connections, it could use one thread per connection, which is not scalable.

[ShaneHarvey]

The tradeoffs here are not worthwhile in my opinion. For example, now if more that 2 connections are in progress, we'll add latency to connection creation. Consider that maxConnecting only limits one pool in one client, while this newly added executor limits all pools of all clients.

If we're going to use run_in_executor, we should just use the default behavior. PYTHON-4440 should be the ticket to replace run_in_executor with real asyncio native OCSP.

[NoahStapp]

The tradeoffs here are not worthwhile in my opinion. For example, now if more that 2 connections are in progress, we'll add latency to connection creation. Consider that maxConnecting only limits one pool in one client, while this newly added executor limits all pools of all clients.

If we're going to use run_in_executor, we should just use the default behavior. PYTHON-4440 should be the ticket to replace run_in_executor with real asyncio native OCSP.

PyOpenSSL does not have a native async API. Asyncio does have some native SSL support, especially around do_handshake, but we need async implementations of both do_handshake and request_ocsp. One option would be for us to write our own native async implementations for both functions.

Absent a different library with native async support for these interfaces, we're left with running synchronous code using run_in_executor.

[ShaneHarvey]

Right I expect PYTHON-4440 to be left in the backlog indefinitely until stdlib ssl or pyopenssl gains async support for OCSP. For now, we can keep using the loop's default executor behavior.

[NoahStapp]

Right I expect PYTHON-4440 to be left in the backlog indefinitely until stdlib ssl or pyopenssl gains async support for OCSP. For now, we can keep using the loop's default executor behavior.

Got it! Sorry, I thought we had said we wanted to change this behavior now, not wait for an external update to the libraries.