Ich habe eine Situation, in der ich durch ein Java-Programm eine javax.naming.ldap.LdapContext und eine search() -Operation darauf anlege - was eine zugrundeliegende Verbindung herstellt. Dann lege ich den Java-App-Thread in den Ruhezustand, währenddessen starte ich den LDAP-Server neu (OpenLDAP, nur um es zu merken). Wenn der App-Thread aufwacht und versucht, eine Operation für das zuvor erstellte LdapContext auszuführen, wird " CommunicationException: Connection is closed " ausgegeben.
Ich möchte die Verbindung wiederherstellen können.
Ich sehe, dass LdapContext eine reconnect() Methode hat - wo ich Kontrollen als null übergebe. Dies hat jedoch keine Auswirkungen. Was ich in der Sun LDAP-Implementierung gesehen habe, war, dass während der Zeit, als der LDAP-Server neu gestartet wurde, das von der Sun-Implementierung verwaltete ConnectionPool die zugrunde liegende com.sun.jndi.ldap.LdapClient -Instanz mit einem "usable = false" markierte. Nach reconnect() call - es ruft einfach ensureOpen() auf, was wiederum prüft, ob das usable -Flag false ist oder nicht - wenn es false ist; dann wirft es CommunicationException - also zurück auf Platz eins.
Meine Frage ist: Wie übersteht eine Java App einen externen Neustart des LDAP-Servers? Ist die Erstellung von neuem LdapContext wieder der einzige Ausweg?
Schätze alle Einsichten.
Hier ist der Stacktrace der Ausnahme:
%Vor%Ich habe eine Situation, in der ich durch ein Java-Programm eine %code% und eine %code% -Operation darauf anlege - was eine zugrundeliegende Verbindung herstellt. Dann lege ich den Java-App-Thread in den Ruhezustand, währenddessen starte ich den LDAP-Server neu (OpenLDAP, nur um es zu merken). Wenn der App-Thread aufwacht und versucht, eine Operation für das zuvor erstellte %code% auszuführen, wird " %code% " ausgegeben.
Ich möchte die Verbindung wiederherstellen können.
Ich sehe, dass %code% eine %code% Methode hat - wo ich Kontrollen als %code% übergebe. Dies hat jedoch keine Auswirkungen. Was ich in der Sun LDAP-Implementierung gesehen habe, war, dass während der Zeit, als der LDAP-Server neu gestartet wurde, das von der Sun-Implementierung verwaltete ConnectionPool die zugrunde liegende %code% -Instanz mit einem "usable = false" markierte. Nach %code% call - es ruft einfach %code% auf, was wiederum prüft, ob das %code% -Flag %code% ist oder nicht - wenn es %code% ist; dann wirft es %code% - also zurück auf Platz eins.
Meine Frage ist: Wie übersteht eine Java App einen externen Neustart des LDAP-Servers? Ist die Erstellung von neuem %code% wieder der einzige Ausweg? Schätze alle Einsichten.
Hier ist der Stacktrace der Ausnahme:
%Vor%Sie sollten beachten, dass dies im Wesentlichen mit dem LDAP-Verbindungspooling zusammenhängt. Wie definiert hier :
Eine Verbindung wird aus dem Pool abgerufen, verwendet, an den Pool zurückgegeben und dann erneut aus dem Pool für eine andere Contextinstanz abgerufen.
Daher kann die Wiederverwendung einer vorherigen Verbindung zu folgendem Problem führen:
Sie können das Verhalten testen, ohne das LDAP-Verbindungspooling zu verwenden, indem Sie
festlegen %Vor%Eine weitere mögliche Ursache könnte das Zeitlimit beim Lesen der LDAP-Vorgänge sein. Tatsächlich wird die Leseoperation nach einem bestimmten Timeout nicht über das Schließen des LDAP-Servers informiert. Weitere Informationen finden Sie in diesem Link
Wir hatten dieses Problem bei der Arbeit. Die Lösung, die wir uns ausgedacht haben (ist vielleicht nicht die beste Antwort). Wurde ein Watchdog-Thread erstellt, der die Verbindung mit einer bestimmten Rate überprüfen würde. Wenn die Verbindung nicht funktioniert hat, wird die Verbindung mit LDAP neu initialisiert.
Aktivieren Sie einfach das JNDI-Verbindungs-Pooling, und hinter den Kulissen wird alles für Sie erledigt. Weitere Informationen finden Sie im JNDI-Handbuch zu Features und in der LDAP-Provider-Dokumentation. Es wird von nur ein paar Eigenschaften gesteuert.
Wir hatten dieses Problem bei der Arbeit. Die Lösung, die wir uns ausgedacht haben (ist vielleicht nicht die beste Antwort). Wurde ein Watchdog-Thread erstellt, der die Verbindung mit einer bestimmten Rate überprüfen würde. Wenn die Verbindung nicht funktioniert hat, wird die Verbindung mit LDAP neu initialisiert.
Sie sollten beachten, dass dies im Wesentlichen mit dem LDAP-Verbindungspooling zusammenhängt. Wie definiert hier :
Eine Verbindung wird aus dem Pool abgerufen, verwendet, an den Pool zurückgegeben und dann erneut aus dem Pool für eine andere Contextinstanz abgerufen.
Daher kann die Wiederverwendung einer vorherigen Verbindung zu folgendem Problem führen:
Sie können das Verhalten testen, ohne das LDAP-Verbindungspooling zu verwenden, indem Sie
festlegen %Vor%Eine weitere mögliche Ursache könnte das Zeitlimit beim Lesen der LDAP-Vorgänge sein. Tatsächlich wird die Leseoperation nach einem bestimmten Timeout nicht über das Schließen des LDAP-Servers informiert. Weitere Informationen finden Sie in diesem Link