Question 1:
When System performs search or update operation over LDAPConnectionPool and if the operation results in error, LDAP will return the error as operation response.
Do we have option to configure the retry times for the recoverable LDAP errors?
(i.e) I need to retry 2 times for search or update operation for the recoverable LDAP errors.
Question 2:
In FailOverSet, If first server is not reachable then it will connect to second server.
Is there any way to configure an retry option for 3 times before reach to second server?
Question 3:
Is't possible to configure the maximum number of simultaneous bind in the connection pool?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Answer 1:
The number of retries is not configurable. If an operation fails in a way that indicates that the connection may no longer be usable, then the connection pool will close that connection, create a new one (using whatever logic is contained in the associated server set to pick the server to which the new connection should be established), and retry the operation on that newly-created connection. This will happen only once. If an operation fails on the newly-established connection, then that failure will be propagated back to the client in the form of an exception.
The set of failure types that can cause a retry is controlled by the health check configured for the connection pool. The retry will only happen if the health check indicates that the failure was because the connection is no longer usable. It doesn't make any sense to retry an operation if it appears that it's still valid and the server isn't having any kind of problem. If you're using a directory server that unpredictably rejects valid requests, then perhaps you should be using a different directory server.
Answer 2:
This question illustrates a misunderstanding of the way that LDAP SDK connection pool works. It does not do load balancing or failover on a per-operation basis but rather on a per-connection basis.
A connection pool may have connections to one or more servers. Whenever a connection is established, the server set associated with the pool decides which server to use, and it may end up trying multiple servers if the initial attempt(s) are either unsuccessful or result in a connection that is deemed unfit for use. But once a connection is established and added to the pool, it is considered as valid and fit for use as any other connection in the pool.
If a connection pool is configured to use the failover server set, then presumably if the most-preferred server is available, all of the connections in the pool will be established to that server. If that most-preferred server becomes unavailable then operations attempted on connections established to that server will fail and the connection pool will establish new connections, and if the most-preferred server is still unavailable then the failover server set should establish a connection to a secondary (or tertiary, or further down the line) server.
If a connection is determined to be invalid but an attempt to create a new connection succeeds to the most-preferred server, then that could indicate that just that one connection was invalid (e.g., maybe the server or some networking equipment had closed it for being idle too long) and the server itself is fine, so the retry will be attempted on the same server. But if the attempt to establish a new connection fails for that same server, I don't see any logic in trying again on that same server. Of course, you're free to write your own server set implementation that retries the same server multiple times before moving on to another server.
Answer 3:
Although you can use a connection pool to limit the number of concurrent operations that may be in progress at any time (by setting createIfNecessary to false and maxWaitTimeMillis to be the maximum length of time to wait for a connection to become available, the pool won't be able to process more concurrent operations than it has established connections), it is not possible to restrict the number of concurrent operations for a particular operation type.
However, if you want to limit the number of concurrent bind operations, then you could accomplish that by creating a separate pool to use for just bind operations. Alternately, you could use a semaphore in your own code so that you need to obtain a permit before starting a bind, and release the permit once the bind has completed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Query with your Answer 1:
If user performs any LDAP operation(Search/Update), if it results in Exception[51 - LDAP Busy]. This problem is not related to the connection. If server is busy, then we have to retry the same operation again to the server (RETRY) with the same connection. Similarly if there is an recoverable ldap exception (Not related to connection) we have to perform Retry option with the same connection.
(a)Is there any way to achieve this using Health Check?
(b)If there is an recoverable ldap exception, Do we have any option for the pool to retry the operation internally for 2 more attempts with the same connection?
Question 1:
In LDAPConnectionPool, we have the option for FailOverServerSet, BindRequest, PoolMinSize , PoolMaxSize.
In FailOverServerSet we have the option to configure different servers and ports. How to configure different passwords for each server similar to port?
Last edit: RPC 2014-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LDAP SDK does not have any option to retry an operation on the same connection. I really do not see any benefit in providing this capability, since the behavior that it exhibits will instead close the connection and retry the operation on a newly-established one. In the case that an operation fails with a "busy" result, that certainly indicates that the server is experiencing problems and should be avoided if there are other servers that are able to handle requests.
If you're using a directory server that randomly fails but then will magically work if you retry exactly the same request, then I would suggest that you look for a different directory server. But if that is not an option, then you could create your own code that implements the retry logic.
With regard to your second question, the connection pool implementations assume that the information contained in all of the servers is identical. It doesn't make sense for a connection pool to include connections to servers with non-identical data sets because you can't really be sure which connection will be used to process a given request. If you need to interact with servers that have different data sets, then it's probably better to have a separate connection pool per data set and have your own application code figure out which one to use for a given request.
If you have some weird case in which the data in the servers is identical except for one account that you want to use to authenticate the pooled connection, then you could create your own server set implementation that authenticates the connection before returning it to the caller. Usually, server set implementations only establish connections without authenticating them, but you could create one that also authenticates the connection, and then provide a null bind request when creating the connection pool.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Neil,
Question 1:
When System performs search or update operation over LDAPConnectionPool and if the operation results in error, LDAP will return the error as operation response.
Do we have option to configure the retry times for the recoverable LDAP errors?
(i.e) I need to retry 2 times for search or update operation for the recoverable LDAP errors.
Question 2:
In FailOverSet, If first server is not reachable then it will connect to second server.
Is there any way to configure an retry option for 3 times before reach to second server?
Question 3:
Is't possible to configure the maximum number of simultaneous bind in the connection pool?
Answer 1:
The number of retries is not configurable. If an operation fails in a way that indicates that the connection may no longer be usable, then the connection pool will close that connection, create a new one (using whatever logic is contained in the associated server set to pick the server to which the new connection should be established), and retry the operation on that newly-created connection. This will happen only once. If an operation fails on the newly-established connection, then that failure will be propagated back to the client in the form of an exception.
The set of failure types that can cause a retry is controlled by the health check configured for the connection pool. The retry will only happen if the health check indicates that the failure was because the connection is no longer usable. It doesn't make any sense to retry an operation if it appears that it's still valid and the server isn't having any kind of problem. If you're using a directory server that unpredictably rejects valid requests, then perhaps you should be using a different directory server.
Answer 2:
This question illustrates a misunderstanding of the way that LDAP SDK connection pool works. It does not do load balancing or failover on a per-operation basis but rather on a per-connection basis.
A connection pool may have connections to one or more servers. Whenever a connection is established, the server set associated with the pool decides which server to use, and it may end up trying multiple servers if the initial attempt(s) are either unsuccessful or result in a connection that is deemed unfit for use. But once a connection is established and added to the pool, it is considered as valid and fit for use as any other connection in the pool.
If a connection pool is configured to use the failover server set, then presumably if the most-preferred server is available, all of the connections in the pool will be established to that server. If that most-preferred server becomes unavailable then operations attempted on connections established to that server will fail and the connection pool will establish new connections, and if the most-preferred server is still unavailable then the failover server set should establish a connection to a secondary (or tertiary, or further down the line) server.
If a connection is determined to be invalid but an attempt to create a new connection succeeds to the most-preferred server, then that could indicate that just that one connection was invalid (e.g., maybe the server or some networking equipment had closed it for being idle too long) and the server itself is fine, so the retry will be attempted on the same server. But if the attempt to establish a new connection fails for that same server, I don't see any logic in trying again on that same server. Of course, you're free to write your own server set implementation that retries the same server multiple times before moving on to another server.
Answer 3:
Although you can use a connection pool to limit the number of concurrent operations that may be in progress at any time (by setting createIfNecessary to false and maxWaitTimeMillis to be the maximum length of time to wait for a connection to become available, the pool won't be able to process more concurrent operations than it has established connections), it is not possible to restrict the number of concurrent operations for a particular operation type.
However, if you want to limit the number of concurrent bind operations, then you could accomplish that by creating a separate pool to use for just bind operations. Alternately, you could use a semaphore in your own code so that you need to obtain a permit before starting a bind, and release the permit once the bind has completed.
Hi Neil,
Thanks for your detailed answer.
Query with your Answer 1:
If user performs any LDAP operation(Search/Update), if it results in Exception[51 - LDAP Busy]. This problem is not related to the connection. If server is busy, then we have to retry the same operation again to the server (RETRY) with the same connection. Similarly if there is an recoverable ldap exception (Not related to connection) we have to perform Retry option with the same connection.
(a)Is there any way to achieve this using Health Check?
(b)If there is an recoverable ldap exception, Do we have any option for the pool to retry the operation internally for 2 more attempts with the same connection?
Question 1:
In LDAPConnectionPool, we have the option for FailOverServerSet, BindRequest, PoolMinSize , PoolMaxSize.
In FailOverServerSet we have the option to configure different servers and ports. How to configure different passwords for each server similar to port?
Last edit: RPC 2014-04-21
The LDAP SDK does not have any option to retry an operation on the same connection. I really do not see any benefit in providing this capability, since the behavior that it exhibits will instead close the connection and retry the operation on a newly-established one. In the case that an operation fails with a "busy" result, that certainly indicates that the server is experiencing problems and should be avoided if there are other servers that are able to handle requests.
If you're using a directory server that randomly fails but then will magically work if you retry exactly the same request, then I would suggest that you look for a different directory server. But if that is not an option, then you could create your own code that implements the retry logic.
With regard to your second question, the connection pool implementations assume that the information contained in all of the servers is identical. It doesn't make sense for a connection pool to include connections to servers with non-identical data sets because you can't really be sure which connection will be used to process a given request. If you need to interact with servers that have different data sets, then it's probably better to have a separate connection pool per data set and have your own application code figure out which one to use for a given request.
If you have some weird case in which the data in the servers is identical except for one account that you want to use to authenticate the pooled connection, then you could create your own server set implementation that authenticates the connection before returning it to the caller. Usually, server set implementations only establish connections without authenticating them, but you could create one that also authenticates the connection, and then provide a null bind request when creating the connection pool.