9
votes

Comment se reconnecter lorsque le serveur LDAP est redémarré?

J'ai une situation dans laquelle via un programme Java, je crée un javax.naming.ldap.ldapcontext et effectuez une recherche () opération sur elle - ce qui fait un connexion sous-jacente. Ensuite, j'ai mis le fil d'application Java pour dormir, au cours de laquelle je redémarre le serveur LDAP (OpenLDAP, juste à noter). Lorsque le thread de l'application se réveille et essaie de faire une opération sur le ldapcontext créé précédemment, il lance " communicationsException: la connexion est fermée ".

Ce que je veux être en mesure de rétablir la connexion.

Je vois que ldapcontext a un reconnect () méthode - où je passe les commandes comme null . Cependant, cela n'a aucun effet. Ce que j'ai vu dans la mise en œuvre Sun LDAP qui, pendant le délai lorsque le serveur LDAP a été redémarré, le ConnectionPool maintenu par la mise en œuvre du soleil a marqué le com.sun.jndi.ldap.ldapclient d'une instance "utilisable = faux ". Sur Reconnect () Appel - Cela appelle simplement Assurez-vous () , lequel vérifie à nouveau si le drapeau utilisable est false ou non - si c'est faux ; Ensuite, il jette communicationException - donc retour à la case unique.

Ma question est la suivante: Comment une application Java survit-elle un redémarrage du serveur LDAP externe? La création d'un nouveau ldapcontext est-il à nouveau le seul moyen de sortir? Apprécier toutes les idées.

Voici la structure de l'exception: xxx


9 commentaires

Je ne pense pas que le problème devienne après le redémarrage du serveur si vous n'avez pas modifié d'utilisateur BIND.


Bonjour Imran, malheureusement - toutes les opérations sur le LDAPContext échouent avec la communicationException, une fois que le serveur LDAP a été redémarré.


Pouvez-vous s'il vous plaît partager du code, comment créer une connexion et l'utiliser pour rechercher?


J'utilise Active Directory. J'ai redémarré serveur et recherche. Cela ne m'a pas donné d'exception et de recherche complète.


Le code est quelque chose comme: ChercheurControls contraintes = Nouveaux SearchControls (); contraintes.SetSearchScope (SearchControls.Subtree_scope); String SearchName = "Test"; Chaîne basé = "dc = foo, dc = com"; Namingénumération namingenum = ldapcontext.Search (Base, SearchName, contraintes); --- Say que je l'ai mis dans une boucle avec un retard de retard .. puis redémarrez le serveur LDAP lorsque la boucle est dormante. Sur le prochain réveil; L'opération de recherche () échoue à lancer une communicationException


Cette exception pourrait arriver lorsque le serveur LDAP est en cours de redémarrage. Pouvez-vous confirmer que, lorsque la boucle continue, LDAP Server était à nouveau repartie après le redémarrage.


Oui, comme je l'ai dit, lorsque la boucle dort - je redémarre le serveur. Ainsi, lorsque la boucle se réveille - le serveur est de retour - Cependant, LDAPContext.Search () échoue.


@Anand: J'ai le même problème que le vôtre. Comme il n'y a pas d'activité 13 janvier , il semble que vous ayez déjà trouvé une solution. Je serai reconnaissant si vous le partageez avec nous. Merci


@LBechir: Nope, pas de solution avec Sun / Oracle LDAP Impl: - /. Il faut toujours garder cela comme "problème connu".


4 Réponses :


0
votes

the Le SDK LDAP non borné fournit un moyen de connecter automatiquement dans lequel cette opération de reconnexion automatique est invisible pour le client.


0 commentaires

-1
votes

Vous devez noter que cela est associé essentiellement à la mise en commun de la connexion LDAP. Tel que défini ici :

Une connexion est récupérée à partir de la piscine, utilisée, retournée à la piscine, puis récupérée à partir de la piscine pour une autre instance de contexte. P> blockQuote>

Ainsi, la réutilisation d'une connexion antérieure peut causer un tel problème: p>

Vous pouvez tester le comportement sans utiliser la mise en commun de la connexion LDAP en réglant P>

com.sun.jndi.ldap.connect.pool=false


1 commentaires

La mise en commun de la connexion est désactivée par défaut. Je ne peux pas avoir beaucoup de sens de votre dernier paragraphe. Si le serveur diminue pendant une lecture, vous serez certainement notifié.



0
votes

Nous avons eu ce problème au travail. La solution que nous avons proposée (peut ne pas être la meilleure réponse). Était de créer un fil de surveillance qui vérifierait la connexion à un taux fixe. Si la connexion n'a pas fonctionné, elle réinitialiserait la connexion avec LDAP.


0 commentaires

2
votes

Activez simplement la mise en commun de la connexion JNDI et il sera tous pris en charge pour vous dans les coulisses. Voir le Guide JNDI en matière de fonctionnalités et de la documentation du fournisseur LDAP. Il est contrôlé par quelques propriétés.


0 commentaires