search

pingidentity / ldapsdk

UnboundID LDAP SDK for Java
Other
327 stars 79 forks source link

Unable to get ServerSet from LDAPConnectionPool #140

Closed mishaobu closed 1 year ago

mishaobu commented 1 year ago

Hi @dirmgr, I am wondering if the inability to access the ServerSet used by a LDAPConnectionPool is an intentional design choice or an oversight. Although there is a method to set ServerSet as well as print its information with LDAPConnectionPool::toString, there is no way to access the ServerSet itself. If you are ok with approving this, I would be happy to make the PR to add a getServerSet method in the connectionPool classes as well as the docs for this.

This feature would be greatly beneficial for me as it would unlock much needed functionality within the performPoolMaintenence method of the LDAPConnectionPoolHealthCheck.

dirmgr commented 1 year ago

I've just committed a change that updates LDAPConnectionPool and LDAPThreadLocalConnectionPool to add getServerSet methods. It'll be included in the next release, although there's not currently a specific timeline for that release.

mishaobu commented 1 year ago

Amazing, thank you!

mishaobu commented 1 year ago

Hey @dirmgr, I was wondering if theres a way in which I can track when a new release may be expected.

To elaborate on why I'm excited for this -- this small addition allows me to non-invasively, and with few lines of code, monitor the uptime of the LDAP servers I connect to by tracking the RoundRobinServerSet blacklist via the built in performPoolMaintence method of LDAPConnectionPoolHealthCheck, as well as dynamically adjust the server set in response.

Thanks again for the quick turnaround on the initial issue, your work is much appreciated.

dirmgr commented 1 year ago

At present, I’m not targeting any specific date for the LDAP SDK release. In recent years, barring any kind of major bug or security issue that warrants an immediate release, we’ve been doing about four releases per year. Sticking to that trend, the next release would probably be around March or April, although that’s not a hard-and-fast rule.

However, you’re free to check out the code, build it for yourself, and use it in your application. As long as you don’t alter the SDK code itself, then we’ll support it to the same extent that we support official releases. We don’t typically guarantee that new APIs that haven’t been in an official release won’t change before the upcoming release, but in this case, I can’t see any reason we would change the new method. We try to keep the repository in an always-production-ready state so that it can be released at any time if necessary, although there’s enough internal housekeeping effort that goes into creating a release that we try not to do it too frequently.