2017-07-20 2 views
0

Wir haben eine Anwendung, die spring-bootembedded tomcat für die Bereitstellung und Standard verwendettomcat-jdbc Connection-Pooling mit MySQL Back-End ohne Anpassung für MySQL oder Tomcat Seite.
Die App hat ein paar Scheduler, die meistens während einer bestimmten Zeit an einem Tag ausgeführt wird, d.h. zwischen dem letzten Cron-Lauf gestern und dem ersten Cron-Lauf heute gibt es mehr als 9 Stunden von Lücke. Wenn der Cron jedoch früher ausgeführt wurde, ist er nie auf das Verbindungsproblem idle gestoßen.

Heute sehen wir eine Fehlermeldung
The last packet successfully received from the server was XXXXXXXX milliseconds ago. The last packet sent successfully to the server was XXXXXXXY milliseconds ago.

Ich versuche immer, kann testOnBorrow mit validateQuery adn/oder testWhileIdle etc als reqd mit dieser Funktion zu erhalten, aber ...

Ich versuche, den Lebenszyklus der aktiven Verbindung in tomcat-jdbc Verbindungspooling zu verstehen. Gemäß der Dokumentation ist der Standardwert für für MySQL 8 Stunden, während der Standardwert für idle_connection_timeout auf Tomcat_jdbc fast 6 Sekunden ist.Tomcat Jdbc Connection Pool aktive Verbindung

  1. Wenn der Standardwert überall verwendet wird, warum ist das Problem nie zuvor aufgetaucht?
  2. Oder ist es etwas, dass die Verbindungen im Verbindungspool tomcat-jdbc jedes Mal aktiv werden, wenn die cron beginnt zu laufen und wird danach im Leerlauf?
  3. Ist es der Status der Spring-Boot-App oder des Schedulers, der einen Unterschied macht?

    Jede Anleitung zur richtigen Ressource wird sehr geschätzt! Danke

Antwort

0

Das Problem ist nicht in der Konfiguration oder im Setup. spring-boot App verwendet spring-data Lib, die die zugrunde liegende connection pool verwendet. Der Pool behandelt die Verbindung (en) gemäß der Implementierung des Verbindungspools. Die Verwendung von @Transactional entscheidet jedoch, wann die zugrunde liegende Verbindung geöffnet wird. Wenn in spring-boot App keine angegeben ist, wird die Standardimplementierung von spring-data während Crud-Operationen geöffnet. Ansonsten wird es während des Methodenaufrufs in der Anwendung geöffnet, die mit @Transactional gekennzeichnet ist.

In meinem Fall war es der letztere .. Nach dem Öffnen der Verbindung lief eine Zeit, die nicht DB-Prozess lief, der die Verbindung machte, um nach dem Öffnen untätig zu gehen, und warf Ausnahme, während sie es später tatsächlich verwendete.

Hoffentlich hilft es anderen ..

Verwandte Themen