The LDAP SDK’s ability to re-establish connections that are no longer valid
depends on the ability to determine that a connection is no longer valid.
Depending on the way in which that connection has been closed, then it may
be that the LDAP SDK won’t be able to detect that a connection was closed
until the next attempt to use it.
As I mentioned, the best ways of dealing with that are to either enable
health checking so that it can detect those kinds of problems in a more
timely manner or to enable a maximum connection age in the pool so that
connections are periodically closed and re-established so that they don’t
encounter the time limit. Also, enabling automatic retry in the connection
pool can help mask these problems so that even if a connection has been
closed in a way that the LDAP SDK wasn’t able to detect, it can
transparently retry the operation in a manner that doesn’t require the
application to do anything.
There have been a lot of changes
<https://docs.ldap.com/ldap-sdk/docs/release-notes.html> since the 6.0.3
release (and it is guaranteed to be backward compatible so updating the the
LDAP SDK should only require dropping in a new jar without any changes to
your code), but I can’t think of anything off the top of my head that would
relate to its ability to detect invalid connections.
Neil
On Thu, Jul 6, 2023 at 9:42 AM mehturt <me...@pr...> wrote:
> Thank you for your response.
> So it seems there's some kind of problem somewhere, I can see that number
> of connections connected to the LDAP server seem to drop below configured
> value. This is over time, when the connections are mostly idle; I can see
> that sometimes for example 2 connections are detected as disconnected but
> only 1 is re-connected. And over time number of connections keep
> decreasing. I am in fact using LDAPConnectionPool.search (not
> get/release), as you recommend. I'm using SDK 6.0.3, were any
> fixes/improvements done in this area in more recent SDK versions?
> Thanks, m.
>
> --
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, July 6th, 2023 at 4:26 PM, Neil Wilson <
> nei...@pi...> wrote:
>
> If the LDAP SDK detects that a connection has been closed or is otherwise
> no longer valid, then it will attempt to re-establish it. This works better
> if you have configured health checking in a manner that actually attempts
> to interact with the server, but depending on how the connection closure
> occurs, it may be able to detect the closure even without special health
> checking.
>
> Also, depending on how you are using the connection pool, you can have it
> automatically retry operations on a new connection if the attempt failed in
> a manner that suggests that the initial connection may no longer be valid.
> For that to work, you need to process operations directly against the pool
> rather than manually checking out connections, processing operations, and
> releasing them back to the pool (for example, by calling
> LDAPConnectionPool.search instead of LDAPConnectionPool.getConnection,
> LDAPConnection.search, and LDAPConnectionPool.releaseConnection). You
> should also enable automatic retry using the
> LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method.
>
> Finally, if the LDAP server is configured to automatically close
> connections after they’ve been idle for a period of time, then I recommend
> that you do at least one of the following:
>
>
> -
>
> Enable health checking in a manner that interacts with the server (for
> example, the GetEntryLDAPConnectionPoolHealthCheck), as this will
> prevent the connection from being seen as idle, and will allow the LDAP SDK
> to most quickly determine if a connection has become invalid. To minimize
> the overhead that it imposes, you can just have it set to be used for
> background checks. If your pool is set up to interact with multiple LDAP
> servers, then it’s probably also helpful to have it invoked when a new
> connection is established.
>
>
>
> -
>
> Configure a maximum connection age for connections in the pool using
> the LDAPConnectionPool.setMaxConnectionAgeMillis method. This will
> cause the pool to close and re-establish connections after they’ve been
> established for the specified length of time so that they never reach the
> idle time limit.
>
>
> Neil
>
>
> On Thu, Jul 6, 2023 at 1:46 AM mehturt <me...@pr...> wrote:
>
>> Thank you Neil.
>> I think this is understood. However, what about the situation where the
>> connections are closed by the remote LDAP server, e.g. for the reason of
>> being idle. Would the pool automatically re-establish those connections so
>> that the number of "active" (connected) connections never drops below
>> configured initial value? Thank you.
>> m.
>>
>> --
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Tuesday, July 4th, 2023 at 6:20 PM, Neil Wilson <
>> nei...@pi...> wrote:
>>
>> 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.*
>>
>>
>>
> *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.*
>
>
>
--
_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._
|