|
From: Neil W. <nei...@pi...> - 2023-07-04 17:24:08
|
Your observation is correct. A connection pool does not ever automatically remove connections from the pool. Whenever you create a connection pool, it will create the requested initial number of connections, which may or may not be less than the maximum number of connections. As long as that number of connections is sufficient to handle the number of concurrent requests that it’s asked to process, then it won’t ever create any more. But if it needs a connection for a new request and there aren’t any already-established connections immediately available, then it will do one of the following: - If the initial number of connections was less than the maximum number of connections, and if the pool hasn’t yet created enough connections to reach the maximum, then it will create a new connection. - If the pool is configured with a nonzero maxWaitTimeMillis (it is zero by default), then it can wait for up to that length of time for an already established connection to become available. - If the pool is configured with createIfNecessary set to true (it is true by default), then it will create a new connection. By this logic, it’s actually possible for the pool to have more than the maximum number of connections established at a time. This would happen under periods of heavy load when the rate of concurrent requests exceeds the maximum configured number of connections. Note that if you really don’t want that to happen and you’d rather have failures if a connection doesn’t become available within the maxWaitTimeMillis, then you can set createIfNecessary to false, and requests to acquire a connection when none are available will fail. Where the maximum number of connections comes into play is when connections are released back to the pool. If the pool’s set of connections that are immediately available to be checked out is larger than the maximum, then the connection being released will be discarded rather than returned to the pool. So the pool will never have more than the configured maximum number of connections immediately available for use, but it might have more than the configured maximum established at any point in time. Once a connection has been established for use in the pool, the pool will keep that connection around. It doesn’t do anything to automatically shrink the pool because it’s very cheap to maintain connections, even if they aren’t used, and because it’s much cheaper to use an already established connection than to have to create a new one if none are available. If you do want to get rid of connections in the pool, then there are a couple of options for doing that manually: - If you want to get rid of a connection instead of releasing it back to the pool, you can use the discardConnection method. If you want to get rid of a specified number of connections, then you could operate in a loop, checking out and discarding connections until you’ve gone through that many. - If you want to shrink the pool so that it contains no more than a specified number of connections, then you can use the shrinkPool method and specify how many connections you want to retain. But in general, there’s not a compelling reason to have the pool automatically get rid of connections once they’ve been created and the number of available connections is no more than the maximum allowed number of connections. Neil Wilson On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss < lda...@li...> wrote: > Hello, > the LDAPConnectionPool constructor has parameters initialConnections and > maxConnections. > I can't find any information about minimal number of connections - is > initialConnections the minimal number of connections as well - meaning the > pool will try to maintain at least initialConnections always? Or can the > number of connections drop below initial? > (This is what I'm seeing in my project, however it's not clear to me > whether that's expected behavior or not). > Thanks, m. > > -- > > > Sent with Proton Mail <https://proton.me/> secure email. > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ |
