"Could not open connection to: jdbc:mysql...."

ReportServer (DE)
1

Hallo!

Folgende Meldung finde ich im Log eines Tomcats wenn ich längere Zeit nicht mit dem Reportserver arbeite:

Ausschnitt:

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 65,912,739 milliseconds ago. The last packet sent successfully to the server was 65,912,740 milliseconds ago. is longer than the server configured value of ‘wait_timeout’. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property ‘autoReconnect=true’ to avoid this problem.
at sun.reflect.GeneratedConstructorAccessor328.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1116)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3853)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2471)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671)
at com.mysql.jdbc.ConnectionImpl.setTransactionIsolation(ConnectionImpl.java:5309)
at com.mchange.v2.c3p0.impl.NewProxyConnection.setTransactionIsolation(NewProxyConnection.java:710)
at net.datenwerke.dbpool.DbC3p0PoolServiceImpl.configureConnection(DbC3p0PoolServiceImpl.java:226)
at net.datenwerke.dbpool.DbC3p0PoolServiceImpl$1.get(DbC3p0PoolServiceImpl.java:144)
… 79 more
Caused by: java.net.SocketException: Connection timed out
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3834)
… 86 more

Ich habe schon im Internet recherchiert, und bin dabei auf einen Ansatz gestoßen dem Parameter ?autoReconnect= true an den jdbc-URL anzuhängen. Jedoch scheint dies im Zusammenhang mit c3p0 nicht zu funktionieren.
Gibt es dafür vl. eine Lösung um dieses Connection Problem zu lösen? Prinzipiell wäre es nicht so schlimm, jedoch bereitet es mir Probleme, wenn eine Einplanung in der Nacht durchgeführt werden sollte, aber aufgrund des gezeigten Problems abgebrochen wird.

Ich denke mal es ist sicher möglich die Timeout-Zeit zu erhöhen, jedoch kann es in meinem Fall schon vorkommen, dass Reports nur im Abstand von 1 Woche automatisch generiert werden (durch Einplanungen)…

Für jede Hilfe wäre ich sehr dankbar!

Lg, Hans Peter

2

Hallo Hans Peter,

sowohl unser Demo- als auch Entwicklungssystem läuft auf Basis von MySQL und der beschriebene Fehler tritt dort nicht auf. Mein Tipp sind die Connection Pool Einstellungen. Wie hast Du denn deine Pool Einstellungen (in /fileserver/etc/datasources/pool.cf) gesetzt. Dort kannst Du C3P0 mitgeben, dass Verbindungen nur eine gewisse Zeit lang benutzt werden sollen, so dass Du gar nicht erst in den MySQL Timeout läufst. Die hierfür spannenden Einstellungen sollten maxConnectionAge und maxIdleTime sein. Im Konfigurationshandbuch ist hierzu noch ein bisschen was geschrieben. Eine Übersicht aller von C3P0 unterstützten Einstellungen findest Du unter: http://www.mchange.com/projects/c3p0/

Grüße
Arno

3

Hallo Arno!
Erstmal vielen Dank für die Hinweise!
Ich habe jetzt die letzten Tage verschiedenste Konfigurationen versucht, bin aber auf kein positives Ergebnis gekommen…
Ich habe in der pool.cf sowohl die Default-Werte verwendet, als auch die Beispielkonfiguration im Anhang des Konfigurationshandbuches.
Dabei habe ich wie von Dir vorgeschlagen die Einstellungen maxConnectionAge und maxIdleTime so abgeändert, dass diese geringer sind als der im MySQL-Server konfigurierte wait_timeout-Wert, jedoch ohne Auswirkung. Der Fehler bleibt immer der gleiche: Sobald der wait_timeout-Wert vom MySQL-Server überschritten wird und ich einen Report ausführe (automatisiert oder auch manuell) bekomme ich die bereits gepostete Exception. Führe ich den Report ein zweites Mal aus funktioniert alles wieder einwandfrei.

Einzige Lösung, die das Problem gelöst hat, ist es das Connection Pooling durch abzustellen. Danach tritt der Fehler nicht mehr auf.

Hier noch kurz zu meiner Konfiguration:
Ich habe für Testzwecke zur Lösung des Problems eine DB eingerichtet, auf die ich nun für die Reportgenerierung zugreife. Den wait_timeout-Wert des MySQL-Server auf dem die DB läuft, habe ich auf einen sehr niedrigen Wert gesetzt um schnell überprüfen zu können ob meine Konfigurationsänderungen eine Wirkung zeigen (wait_timeout = 60 Sekunden).

Meine Konfiguration in der pool.cf (damit bekomme ich aber immer den Fehler):

<?xml version="1.0" encoding="UTF-8"?> 40 10 10 500 60000 40 30 10 select 1 true

LG, Hans Peter

4

Vielleicht ist die Info noch hilfreich:
Bei der Initialisierung des c3p0 Pools werden die Parameter der pool.cf unter “properties” hinterlegt (z.B. testConnectionOnCheckout=true).
Bei genauerer Betrachtung des Server-Logs zeigt sich aber, dass das testConnectionOnCheckout noch einmal aufscheint, aber hier unverändert auf “false” bleibt.

07:49:09,976 INFO AbstractPoolBackedDataSource:522 - Initializing c3p0 pool… com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement → 3, acquireRetryAttempts → 30, acquireRetryDelay → 1000, autoCommitOnClose → false, automaticTestTable → null, breakAfterAcquireFailure → false, checkoutTimeout → 0, connectionCustomizerClassName → net.datenwerke.dbpool.hooks.C3p0ConnectionHook, connectionTesterClassName → com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName → 1hge2tz8w18ncq6yormd61|366146ae, debugUnreturnedConnectionStackTraces → false, description → null, driverClass → com.mysql.jdbc.Driver, factoryClassLocation → null, forceIgnoreUnresolvedTransactions → false, identityToken → 1hge2tz8w18ncq6yormd61|366146ae, idleConnectionTestPeriod → 0, initialPoolSize → 3, jdbcUrl → jdbc:mysql://[ip]:3306/testDB, maxAdministrativeTaskTime → 0, maxConnectionAge → 0, maxIdleTime → 0, maxIdleTimeExcessConnections → 0, maxPoolSize → 15, maxStatements → 0, maxStatementsPerConnection → 0, minPoolSize → 3, numHelperThreads → 3, preferredTestQuery → null, properties → {initialPoolSize=10, maxPoolSize=40, acquireRetryAttempts=10, maxIdleTime=120, user=, preferredTestQuery=select 1, checkoutTimeout=60000, testConnectionOnCheckout=true, maxConnectionAge=120, password=, acquireRetryDelay=500, idleConnectionTestPeriodInSeconds=60}, propertyCycle → 0, statementCacheNumDeferredCloseThreads → 0, testConnectionOnCheckin → false, testConnectionOnCheckout → false, unreturnedConnectionTimeout → 0, userOverrides → {}, usesTraditionalReflectiveProxies → false ]

5

Hallo Hans Peter,

Du hast Recht, hier ist ein Fehler in der 2.1 Version. Die Einstellungen aus der Konfigurationsdatei werden leider nicht korrekt an den Connection-Pool weitergegeben. Wir hatten mit unserem MySql wohl einfach “Glück”, das unsere Konfiguration zu den Default-Werten gepasst hat.

Das Problem ist behoben, wir werden in den nächsten Tagen dann eine rc2-Version, mit den entsprechenden Korrekturen veröffentlichen.

Grüße
Thorsten