Metric to show potentially available connections

[david0]

Maybe its just me, but I would be mostly interested in if the connection pool is exceeded (maxConnections exceeded).

I guess this can implied by numSuccessfulCheckoutsAfterWait.
But... for me it would be more intuitive to see the available connections in the pool including the ones that CAN be established, but are not yet (thats what differentiates it from getNumAvailableConnections).

Is there any chance to get that metric from the SDK?

[dirmgr]

I’m not really sure how feasible this is because the connection pool may not work the way you think it does.

The maximum number of connections for a connection pool doesn’t necessarily represent the maximum number of connections that can be established at any given time. Instead, it’s the maximum number of connections that can be immediately available for use at any given time. In a busy client that is making heavy use of the connection pool, you can actually have more connections established at any given time than the specified maximum, at least in the default configuration.

The reason for this is the “create if necessary” property, which is set to true by default. This means that if there’s a request to get a connection from the pool (or to perform an operation against the pool, which checks out a connection internally), the pool can create a new connection to use for that if there aren’t any immediately available. This is good because it prevents having an incorrectly sized pool from causing operations to be unnecessarily rejected. If demand on the pool decreases and connections start to be released back to the pool faster than they are being requested, then the number of available connections will be allowed to grow up to the configured maximum, and an attempt to release a connection when the number of immediately available connections is already at its maximum will cause that connection to be closed.

In addition to providing better behavior under heavy load, having “create if necessary” set to true by default also provides better behavior in the case of applications that leak connections. If you have an application that checks out a connection and neglects to release it back to the pool (maybe after an unexpected failure while attempting to perform an operation using that connection, which is hopefully a rare condition), then it’s likely better to allow the application to continue by letting the pool create new connections to replace leaked ones than it would be to let it run out of connections and cause every attempt to use it to fail.

Ultimately, the pool doesn’t really keep track of all of the connections that it has created, but just the ones that are immediately available for use, and that’s what it reports as the number of available connections.

It is, of course, possible to set “create if necessary” to false, and in that case, then once the pool has created the maximum number of connections, it won’t ever create any new ones except as replacements for connections that have become invalid or those that have been established for the maximum allowed connection age. With this setting, it is possible for the pool to reject attempts to obtain a connection if all of the connections are already in use (and in this case, “leaked” is effectively the same as “in use”). You can have the pool wait for up to a specified maximum period of time for a connection to become available in case one happens to be released, or you can have it reject attempts immediately. However, I’m not sure that I would recommend actually setting that property to false because it just seems likely to cause problems for your application in the event that it either leaks connections (which can probably be effectively mitigated by configuring the server to automatically close connections that have been idle for too long) or doesn’t have the pool properly sized.

[david0]

Oh I see, thanks for the detailed explanation. I would have expected that its not allowed to grow above that limit, but I can see that it might be like the choice between a rock and a hard place to how to set "create if necessary" in this situations.

So another counter that might help in my situation would be "number of used connections". Would that be equal to numSuccessfulCheckouts-numReleasedValid? Just as long as no defunct connections are closed I guess?!
Maybe we just have to track them on our own.

(Feel free to close this issue anytime, its not an "issue", more a discussion/feedback thing)

[dirmgr]

It does look like there's not currently a great way to see how many connections have been checked out from but never released back to the pool in some way (as valid or defunct, as well as connections that have been discarded). I'll look into adding that, although it might not be for a couple of weeks.