Fehler bei RMI in Verbidung mit JDBC

[Recco]

Hallo Forum,

ich bekomme eine Fehlermeldung, mit der ich absolut nichts anfagen kann. Vielleicht kann ja einer von Euch mir weiterhelfen.

Ich habe einen Server, auf dem eine RMI Registry läuft und in der ein Objekt gebunden ist. Mit einem Client kann ich auf das Objekt zugreifen und dessen Methoden benutzen. Mit den Methoden lese ich zyklisch Werte aus einer Datenbank (befindlich auf dem selben Server).

Eine ganz Zeit lang geht das gut und nach ca 15 Min bekomme ich folgende Exception:

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operati
ons allowed after connection closed.Connection was implicitly closed due to unde
rlying exception/error:


** BEGIN NESTED EXCEPTION **

java.lang.OutOfMemoryError
MESSAGE: Java heap space

STACKTRACE:

java.lang.OutOfMemoryError: Java heap space
        at com.mysql.jdbc.MysqlIO.readPacket(MysqlIO.java:632)
        at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:407)
        at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2534)
        at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1749)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2159)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2548)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2477)
        at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1422)
        at de.ssv_embedded.ba.tv.server.ServerImpl.getAktuelleMessung(ServerImpl.java:354)
        at de.ssv_embedded.ba.tv.server.ServerProxy.getAktuelleMessung(ServerProxy.java:130)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
        at sun.rmi.transport.Transport$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)


** END NESTED EXCEPTION **


        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.lang.reflect.Constructor.newInstance(Unknown Source)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
        at com.mysql.jdbc.Util.getInstance(Util.java:381)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926)
        at com.mysql.jdbc.ConnectionImpl.checkClosed(ConnectionImpl.java:1115)
        at com.mysql.jdbc.ConnectionImpl.createStatement(ConnectionImpl.java:2392)
        at com.mysql.jdbc.ConnectionImpl.createStatement(ConnectionImpl.java:2374)
        at de.ssv_embedded.ba.tv.server.ServerImpl.getAktuelleMessung(ServerImpl.java:350)
        at de.ssv_embedded.ba.tv.server.ServerProxy.getAktuelleMessung(ServerProxy.java:130)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
        at sun.rmi.transport.Transport$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

Wäre über jede Hilfe dankbar

Gruß Recco

 

[SlaterB]

Fehler bei RMI in Verbidung mit JDBC
klingt wie
Fehler beim Auto fahren in Verbindung mit Einkaufen im Supermarkt

die beiden Dinge haben normalerweise nichts miteinander zu tun,
OutOfMemoryError ist aber wirklich einer der weniger Fehler, der alle Vermutungen rechtfertigt,
dennoch kann man immer noch erstmal testen, ob es nicht ohne RMI genauso zur Exception kommt,

wer fragt denn da über RMI etwas ab, ist das ein automatischer Thread?
baue den testweise genauso in den Server ein, so dass der Server selber die gleiche Anzahl JDBC-Anfragen stellt,
nur alles ohne RMI

 

[tuxedo]

Klingt für mich als würde in dem zyklischen Abfragen das Resultset und/oder andere JDBC relevante Dinge nicht ordnungsgemäß geschlossen werden, so dass der Speicher wieder freigegeben wird, und deshalb der Speicher voll läuft bis nach 15min die JVM die Flügel streckt...

- Alex

 

[Recco]

Fehler bei RMI in Verbidung mit JDBC
klingt wie Fehler beim Auto fahren in Verbindung mit Einkaufen im Supermarkt

Da habe ich mich etwas unglücklich ausgedrückt, da hast du recht, war schon spät gestern nacht

wer fragt denn da über RMI etwas ab, ist das ein automatischer Thread?
baue den testweise genauso in den Server ein, so dass der Server selber die gleiche Anzahl JDBC-Anfragen stellt,
nur alles ohne RMI

Japps, ein Thread fragt zyklisch per RMI die Datenbank ab. Müsste das dann ausprobieren wie sich das ganze ohne RMI verhält.

Klingt für mich als würde in dem zyklischen Abfragen das Resultset und/oder andere JDBC relevante Dinge nicht ordnungsgemäß geschlossen werden, so dass der Speicher wieder freigegeben wird, und deshalb der Speicher voll läuft bis nach 15min die JVM die Flügel streckt...

Das könnte evtl. des Problems Lösung sein. Ist es denn auf jeden Fall erforderlich das Resultset mit einem close() zu beenden? Habe das bisher nicht gemacht, da es in der Literatur die ich als Hilfestellung verwendet habe nicht genutzt wurde. Werde das gleich mal ausprobieren und berichten.

Recco

 

[SlaterB]

dann auch das Statement und vor allem die Connection schließen, falls du nicht immer exakt dieselbe verwendest

 

[tuxedo]

Naja, zumindest das Statement solltest du closen:

Releases this Statement object's database and JDBC resources immediately instead of waiting for this to happen when it is automatically closed. It is generally good practice to release resources as soon as you are finished with them to avoid tying up database resources.

Calling the method close on a Statement object that is already closed has no effect.

Note:When a Statement object is closed, its current ResultSet object, if one exists, is also closed.

 

[Recco]

Problem gelöst!

Da ich das Statement und das Resultset nach jedem Aufruf wieder schließe läuft die Anwendung fehlerfrei! Habe das jetzt ne gute Stunde getestet.

Vielen Dank für Eure Hilfe!

Recco