Replies: 2 comments 1 reply
-
No. Having a client-per-connection won't gain you anything.
If you've got a specific use case where you want lots of connections but they're mostly idle, then that seems sensible. (?) |
Beta Was this translation helpful? Give feedback.
-
|
The problem I have is that the connections consumed by these long-lived requests stay ACTIVE (this is a form of long-polling, essentially). So the total number of objects that the thing can possibly handle is limited by the size of the connection pool. This thing needs to be able to handle potentially 1000s objects. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have an application that does a lot of Kubernetes watches, which means a lot of long-lived HTTP connections. This results in a lot of PoolTimeout errors :-)
What is the recommended thing to do here? Massively increase the size of the connection pool? Have a client per connection?
Beta Was this translation helpful? Give feedback.
All reactions