2016-10-10 3 views
3

Ich habe mit diesem Problem seit Ewigkeiten gekämpft und ich kann nicht für das Leben von mir herauszufinden, was das Problem ist. Lassen Sie mich für den Stapel auf die Bühne setzen wir verwenden:Gebrauchte jdbc Verbindungen scheinen undicht zu sein und ich kann nicht herausfinden, warum

  • Web-basierte Java 8 Anwendung
  • GWT
  • Hibernate 4.3.11
  • MySQL
  • MongoDB
  • Frühling
  • Tomcat 8 (zum Beispiel Tomcat Connection Pooling anstelle von C3PO)
  • Hibernate Search/Lucene
  • Terracotta und ehcache

Das Problem ist, dass alle paar Tage (manchmal jeden zweiten Tag, manchmal einmal alle 10 Tage, es variiert) in den frühen Morgenstunden, unsere Anwendung „sperrt“. Um es zu verdeutlichen, es stürzt nicht ab, man kann sich einfach nicht einloggen oder nichts tun. Alle Hintergrundaufgaben - alles - halt einfach. Wenn wir versuchen, uns einzuloggen, wenn es sich in diesem Zustand befindet, können wir in unserer Protokolldatei sehen, dass es uns als gültigen Benutzer authentifiziert, aber es wird keine Antwort gesendet, so dass die Anwendung nur "spinnt".

Das einzige Muster, das wir bisher gefunden haben, als diese "Lock-ups" auftraten, ist, dass es passiert, wenn unsere morgendlichen geplanten Aufgaben oder SAP-Importe ausgeführt werden. Es ist nicht immer derselbe Prozess, der ausgeführt wird, manchmal erfolgt die Sperre während eines unserer SAP-Importe und manchmal während der internen geplanten Taskausführung. All diese Dinge haben gemeinsam, dass sie außerhalb der Geschäftszeiten (zwischen 1.00 und 6.00 Uhr) laufen und dass es sich um sehr intensive Prozesse handelt.

Wir verwenden JavaMelody für die Überwachung und was wir jedes Mal sehen ist, dass beginnend zu verschiedenen Zeiten in diesem 1 - 6 Uhr Fenster die Anzahl der verwendeten jdbc Verbindungen einfach zu spike (wie im angehängten Bild). Sobald dies beginnt, ist es nur noch eine Frage der Zeit, bis das Lock-up auftritt und die einzige Möglichkeit, es zu lösen, besteht darin, Tomcat zurückzuschlagen und dadurch die Anwendung neu zu starten.

Wie ich sagen kann, sind Speicher, CPU, etc, alle in Ordnung, wenn die Sperre auftritt, die einzige Sache, die aussieht, wie es ein Problem hat, ist die ständig steigende Anzahl der verwendeten JDBC Verbindungen.

Ich habe den Code für unsere Transaktionsverwaltung so oft überprüft, um sicherzustellen, dass Transaktionen korrekt abgeschlossen werden (der Transaktionsverwaltungscode ist ziemlich altmodisch: Explizite Begin und Commit in Try Block, Rollback in Catch Blocks und Entity Manager) nah in einem Endblock). Es scheint mir alles richtig zu sein, also bin ich wirklich, wirklich ratlos. Außerdem habe ich den Hibernate-Verbindungsfreigabemodus kürzlich explizit auf after_transaction konfiguriert, aber das Problem tritt immer noch auf.

Die andere seltsame Sache ist, dass wir mehrere Instanzen der gleichen Anwendung für verschiedene Clients ausführen, und dieses Problem tritt nur regelmäßig für einen Client auf. Sie sind unser Client mit den meisten zu verarbeitenden Daten, und obwohl alle Kunden diese geplanten Aufgaben ausführen, ist dieser große Client der einzige mit SAP-Importen. Aus diesem Grund dachte ich ursprünglich, dass die SAP-Importe das Problem seien, aber es wurde kurz nach 1 Uhr heute Morgen geschlossen und das war ein paar Stunden bevor die Importe überhaupt begannen zu laufen. In diesem Fall wurde es während einer internen geplanten Taskausführung gesperrt.

Hat jemand eine Idee, was dieses seltsame Verhalten verursachen könnte?Ich habe alles untersucht, was mir einfällt, aber ohne Erfolg.

enter image description here

+0

Sie sagen, dass die Transaktionen geschlossen werden, aber schließen Sie die Entity Manager? Sie müssen sie auch schließen, um die Verbindung zum Pool freizugeben. – coladict

+0

@coladict Ich denke nicht, dass das wahr ist, weil, wie ich bereits erwähnte, ich den Verbindungsfreigabemodus auf nach der Transaktion setze, so sollte es sie bei commit/rollback freigeben, soweit ich es aus den Dokumenten verstehe. Wie auch immer, es ist ein strittiger Punkt, da ich in meiner Frage gesagt habe, dass ich den Entity Manager in einem finally Block schließe. – brent777

+1

Nun, es gibt die "Geöffnete jdbc-Verbindungen" Link im Abschnitt "Systeminformationen" der Überwachungsseite, damit Sie Lecks finden können. Wenn es offene Verbindungen gibt, erhältst du das StackTrace von dem, wo die Verbindung erstellt wurde, dessen Spitze wahrscheinlich irgendwo in Hibernate sein wird, aber du musst nur runter gehen, bis du deine Klassen erreichst. – coladict

Antwort

0

Nach einiger Zeit und viel Versuch und Irrtum gelang es meinem Team und mir, dieses Problem zu lösen. Es stellte sich heraus, dass die Spitze der JDBC-Verbindungen nicht die Ursache der Sperren war, sondern eine Folge der Sperren. Apache Terracotta war der Schuldige. Es wurde einfach unempfänglich, wie es scheint. Es könnte ein Problem bei der Ressourcenzuteilung gewesen sein, aber ich denke nicht, da dies auch auf Servern geschah, die wenig genutzt wurden und über mehr als genug Ressourcen verfügten.

Zum Glück brauchten wir Terracotta eigentlich nicht mehr, also entfernte ich es. Wie ich in der Frage gesagt habe, erhielten wir diese Lock-ups alle paar Tage - mindestens einmal pro Woche, jede Woche. Seit dem Entfernen haben wir seit 4 Monaten keine solchen Sperren mehr. Wenn also jemand anderes das gleiche Problem hat und Sie Terracotta verwenden, versuchen Sie es fallen zu lassen und die Dinge könnten wie in meinem Fall richtig ausgehen.

-1

Wie coladict sagt, müssen Sie bei „Geöffnet JDBC-Verbindungen“ Seite im javamelody Monitoring-Bericht sehen und vor dem Server „sperren“.

Es tut uns leid, wenn Sie das um 2 Uhr oder 3 Uhr morgens tun müssen, aber vielleicht können Sie einen wget-Befehl automatisch in der Nacht ausführen.

Verwandte Themen