Servlet - out of memory

[waynel]

Hallo Welt !!!
Ich mach mir gerade mal ne kleine Webanwendung mit Tomcat.
Mein Problem ist, daß nach ca. 100 Aufrufen nur noch "out of memory"-Meldung im Browser kommt, und jstat -gcpermcapacity sagt mir, daß >80MB verbraten sind (PGC~PGCMX)

Die Seiten werden aus einer DB generiert.Ich vermute zwar, daß der Fehler nicht in verwaisten Connections liegt, aber trotzdem mal ein Beispiel:

private void someOutput(){
  PrintWriter out = getWriter();
  Statement SQL = null;
  ResultSet res = null;
  Connection con = null;
  try
   {
     Class.forName("com.mysql.jdbc.Driver");
   }
   catch (Exception e)
   {
     out.println(" Database-error : "+e.toString()+"");
   }
   try
   {
     String query = -die Abfrage eben -
     con = DriverManager.getConnection("jdbc:mysql:-path-?user=-username-&password=-passwort-");
     SQL = con.createStatement();
     res = SQL.executeQuery(query);
     res.first();
     out.println(res.getString();
   }catch(Exception e){out.println(e.toString());}
   finally{
      try { if (res != null) res.close(); } catch(Exception e){}
      try { if (SQL != null) SQL.close(); } catch(Exception e){}
      try { if (con != null) con.close(); } catch(Exception e){}
    }
}

Wenn hier was falsch ist, lasse ich mich gern belehren.

Der grobe Aufbau der Seite ist wie folgt:

public class mainPage extends HttpServlet{
  // Globale Variablen
  PrintWriter gwriter;
  public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException{
    PrintWriter out=res.getWriter();
    res.setContentType("text/html");
    setWriter(out);
    header();
    page();
    footer();
    out.close();
    this.destroy();
  }

   private void setWriter(PrintWriter out){
    gwriter = out;
  }

  private PrintWriter getWriter(){
    return gwriter;
  }
}

header, page, footer entsprechen vom Aufbau her o.g. someOutput.
Zusätzlich nutze ich noch eine Hand voll Variablen für Zähler (int), Strings, und zwei Arrays (String[10]).
Muß ich diese am Ende explizit "closen", "freen","destroyen" oder sonstwas?
Wieviele PrintWriter werden von der VM erzeugt ?
Sind am Ende alle wieder geschlossen und aus dem Speicher entfernt ?

Ich bin über jede Hilfe dankbar.

Habe den gleichen Text schon im Forum von java.de gehabt, leider ohne Erfolg :-(

Und nochwas : wie kann man vermeiden, SQL. con und res mit "null" zu initialisieren ?
Irgendwie finde ich das unschön.

 

[waynel]

Kann das bitte jemand in den Enterprise JAVA Bereich verschieben ?

 

[SlaterB]

modifiziere dein Programm ein wenig, ist die Belastung weg, wenn die DB-Anfrage wegfällt?
wie ist es wenn du die Anfrage stellst aber das ResultSet nicht ausgibts,
wie ist es bei Anfragen mit weniger Ergebnissen
usw.

 

[ms]

Was genau macht denn this.destroy()?

Instanzvariablen in einem Servlet sollten mit Vorsicht (am besten gar nicht) verwendet werden. Ich fürchte, dass da dein Fehler liegt.
Übergebe den Printwriter als Methodenparameter, anstatt ihn im Servlet zu deklarieren.

Am besten zeigst du mal den ganze Code.

ms

 

[waynel]

Danke erstmal.

Ich kann mal versuchen, den Code soweit einzudampfen, das er normal postbar wird.
Einen neuen Verdächtigen habe ich auch schon: Die Session.
Ohne die hab ich den Fehler noch nicht provozieren können, trotz aller DB-Anfragen und Ausgaben.
Eine sehr ähnliche Anwendung ohne Sessions läuft seit 14 Monaten in einer 64MB VM ohne Neustart.
Habe ich im ersten Post nicht mit angegeben, aber die Wertübergabe erfolgt über Sessionattribute.
Klappt auch ganz wunderbar, aber kann es sein, daß durch das this.destroy() bei jedem neuen Aufruf,
eine neue kopie der bestehenden Session angelegt wird ?
Der Tomcat-Manager zeigt üner eine Sitzung nur eine Session an, die nach session.invalidate() auch weg ist.
Ich probier mal this.destroy() rauszunehmen.

 

[SlaterB]

du solltest die Session nicht unbedingt destoryen oder ähnlich komisches,
die Session wird sicherlich irgendwo intern in Frameworks referenziert und kann ruhig automatisch entfernt werden,
vielleicht reagiert auch jemand gereizt, wenn die Session kaputt ist

wenn die Session x MB Daten enthält, dann entferne einfach die Daten aus der Session,
for (all key) {
// remove key oder als schlechte Alternative put (key, null)
}
fertig, ohne irgendwas zu demolieren,

 

[maki]

das hier könnte dich interessieren:
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSessionListener.html

 

[waynel]

Ich habe das Problem, den stetigen Anstieg der PermCapacity, reproduzieren können.
Um es etwas spannender zu machen, erstmal mein Vorgehen:

EXKURS

Ich habe den Quelltext so geändert, daß die Session-Id angezeigt wird, und in einem zweiten Fenster
jstat -gcpermcapacity -h10 18819 10000 laufen lassen.
Da schon PGC>PGCMN war, habe ich jede Änderung von PGC sofort gesehen.
Dann mir zwei Browser auf die App losgegangen. Login, Logout, Session-Timeout, DB-Aktionen volles Programm.
-> nicht die geringste Änderung.
Die App im Tomcat-Manager neu geladen (wiederholt) und die Seite bebrowst.
-> keine änderung, nichtmal die Session-Ids haben sich geändert.

Dann : neu kompiliert, neu geladen und ... PGC stieg an, andere Session-Id.

EXKURS Ende

Meine Interpretation :

Ich glaube/hoffe, daß der Tomcat nach dem Compile/Restart die App samt Session einfach vergißt.
So kann der Tomcat die Session auch nicht mehr timeouten. Die VM schiebt die Session in den Müll, denn um das Aufräumen kümmert sich ja der Servlet-Container. Sonst hätte die VM die Session ja beim beenden der App auch die Session beendet, oder ?
Der Zuwachs von PGC war abhängig von der beim Reload geladenen Seite (400kb - 3,5 MB), bis zum Tilt.
Ein SessionEventListener hätte da auch nichts genützt, da ja kein Event signalisiert wird, der maxInactivityTimeout greift auch nicht mehr, da die VM keine Session mehr sieht.
Aber irgendwas muß noch auf diesen Datenmüll verweisen, da der GC nicht greift.

Sollte ich komplett daneben liegen, oder das reiner Zufall gewesen sein, oder sonstwas, immer her mit den Kommentaren.
Ich sehe das Problem vorerst als gelöst an, und kann mich jetzt mit den vollen 10% meines geistigen Potentials wieder an die Programmierung machen.

Übrigens : this.destroy() ist raus und der PrintWriter wird als Aufrufparameter übergeben. Vielleicht mache ich das mit der Session auch. (Ein Programm mit globalen Variablen ist ein falsches Programm - Aussage eines Pascal-Programmierers)

Wie kann ich die Initialisierung mit NULL vermeiden ? Da ich selbst aus der Pascal-Ecke komme, sieht das für mich immer falsch aus. da läßt man eine Variable uninitialisiert, aber initialisiert nicht mit "nichts".

Wenn das Problem nicht mehr auftritt, mache ich ein Häkchen bei SOLVED, sobald ich es gefunden habe.

Nochmals Dank an alle.