Какова самая простая (то есть наименее сложная) возможная операция LDAP

Question

Я реализовал пул для соединений LDAP, используя Apache commons-pool. Я не могу использовать функцию пула, предоставляемую JNDI (http://download.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html), потому что я использую соединение SSL (с настраиваемой (предоставляемой Oracle) фабрикой сокетов (java.naming.ldap.factory.socket набор значений env), которая исключает контекст из пула JNDI) с сервером LDAP и таким образом, средство объединения в JNDI автоматически отключается, даже если установлено соответствующее свойство объединения.

Теперь дело доходит до того, что объединенный экземпляр InitialDirContext возвращается в пул и нуждается в проверке на предмет того, является ли он все еще пригодным к использованию и не был закрыт пользователем или потерял соединение с сервером LDAP из-за других причин.

Здесь я в данный момент ищу DN конкретного пользователя, о котором известно, что он существует:

 final InitialDirContext ctx = internalPooledLDAPConnection.getCtx();
 final Subscriber sub = internalPooledLDAPConnection.getSub();

 SearchControls ctls = new SearchControls();
 ctls.setSearchScope(2);
 ctls.setReturningAttributes(new String[] { "dn"});
 NamingEnumeration resultSet = ctx.search(sub.getUserSearchBase()[0], "(&(objectclass=*)(uid=orcladmin))", ctls);

Если эта операция не вызывает каких-либо исключений, то InitialDirContext внутри моего внутреннего пула Ldap-соединения все еще может использоваться и может быть безопасно передан из пула для повторного использования.

Однако мне интересно, является ли это «самой дешевой» проверкой работоспособности соединения, которую можно выполнить здесь, или существует ли гораздо более дешевая операция LDAP, которую я мог бы использовать вместо этого.

Answer 1

Операция сравнения LDAP, вероятно, будет более эффективной, чем поиск, потому что есть только один ответ (при поиске, который соответствует записи, у вас будет два ответа - один для записи и второй, чтобы указатьконец результатов поиска).

Однако вы также можете рассмотреть альтернативы JNDI, так как предоставляет общеизвестно плохой API для LDAP.Существуют и другие библиотеки Java для взаимодействия с LDAP, которые намного лучше, чем JNDI.В частности, UnboundID LDAP SDK для Java (для которого я являюсь разработчиком) предоставляет многофункциональный, простой в использовании и высокопроизводительный API-интерфейс для взаимодействия с LDAP.Он обладает широкими возможностями по созданию пулов соединений, включая проверку работоспособности, отработку отказа и распределение нагрузки.См. http://www.unboundid.com/products/ldap-sdk/docs/advantages/comparison.php для сравнения возможностей, предоставляемых UnboundID LDAP SDK с JNDI и Netscape Directory SDK для Java.

Answer 2

Мы используем проверку для элемента управления 0.0.0.0.0, которая, конечно, никогда не может существовать, чтобы проверить, активно ли соединение. Насколько я помню, именно так проверяет вызов OpenLDAP (jldap). Поскольку rootDSE для элементов управления, как правило, разрешен для анонимных пользователей, он будет проверять работоспособность соединения, но не проверять состояние привязки.

Answer 3

У меня была похожая проблема (я катал свой собственный пул).Мой подход состоял в том, чтобы ожидать, что любое объединенное соединение будет мертвым.Я позволил пулу выполнить любой запрос дважды: 1-й раз он может завершиться неудачей, поэтому заново подключитесь и попробуйте снова, но сбои 2-й попытки являются реальными и распространяются вверх.

Подводя итог, вместо использования конкретного запроса pingЯ позволил собственным запросам приложения выступать в качестве потенциальных пингов.

Что касается самого дешевого запроса, то он, вероятно, довольно дешевый!Возможно, вам даже не нужно связываться с этим - я не помню.

// The rootDSE attributes, Microsoft Active Directory
Attributes attrs = ldapContext.getAttributes("");
String ldapRootDN = (String) attrs.get("rootDomainNamingContext").get(0);

Answer 4

Привязка к LDAP настолько проста, насколько это возможно. Это метод Reconnect () в JNDI.

Однако должны быть оговорки относительно того, что вы делаете. Если пул отключен по протоколу SSL, для этого должны быть причины безопасности, поэтому вам необходимо выполнить собственный анализ безопасности при разработке собственного пула.

Answer 5

Почему бы не отправить неверный поиск неизвестного или мусорного атрибута.Все дело просто в пинге, а не в самом процессе.