Speicherverwaltung Java + Lotus Notes Domino

[Ralf_M_Petter]

Die Erklärung mit dem das finalize nicht zuverlässig ist, stimmt natürlich auch.

Übrigens ist soweit ich weiß bei SWT ja die selbe Problematik.

Grüße

Ralf

[flaite]

Yup. Ich habe diese Problematik vor 2 Jahren bestimmt überbetont.
(ich habe Bier getrunken und werde esoterisch)
Der wahre Zen ist vermutlich sogar, dass dies ein Teil einer noch größeren Problematik ist, zu der beispielsweise auch wirklich threadsafe HttpConnections mit apache.jakarta.commons.HttpClient gehören. Oder sicher LotusScript programmieren, wovon Bernhard manchmal spricht.
Manche Ressourcen sind in einem Netzwerk einfach knapp und man muß das als Programmierer managen. Die Frage ist nur welche, wann und wie.
Andere Ressourcen sollen nur genau einmal und nicht dupliziert oder nicht dupliziert pro Thread vorhanden sein (ok, threadsafe gehört hierhin). Auch das muß man oft als Programmierer selbst managen. Aber es ist irgendwie auch nur ein Aspekt der Ressourcen-Management-Thematik.
Und das kann nicht durch Tools, Frameworks, Design Patterns oder ähnlichem wirklich aufgelöst werden, da es oft auf den Einzelfall ankommt. 

[koehlerbv]

... (ich habe Bier getrunken und werde esoterisch) ... Oder sicher LotusScript programmieren, wovon Bernhard manchmal spricht.

Irgendwie mag ich es, wenn Du Bier getrunken hast 

Bei der Fülle der gegebenen Möglichkeiten ist der Einsatzspielraum von LotusScript etwas ... dünn, sagen wir mal. Dafür sollte man es dann aber wenigstens beherrschen und das, was man damit bezwecken will. Und damit schliesst sich wieder der Kreis, denn das gilt für jede "Ausdrucksform" gegenüber der Maschine.

Ich freue mich gerade (wieder) auf ein grosses Projekt, in dem sich die verschiedensten Welten sich vereinigen müssen. Ich glaube, dabei wird wie immer keiner dümmer. Ich bin da schon sehr gespannt.

Bernhard

[Thomator]

@Axel,
die GarbageCollection ist (zumindest Ansatzweise) schon beeinflussbar. Die JVM-Parameter -XMX und -XMS sind dafür maßgeblich mitentscheidend.

Beispiel: JMeter
Ich hatte JMeter immer mit den Standard-Einstellungen laufen, wo XMX = XMS ist. Wenn ich also mit zu vielen Threads einen Test gestartet habe kam immer ein OutOfMemory.
Dann habe ich mal gelesen, dass der XMS-Wert bestimmt, wann die Garbage-Collection anfängt, 'gründlich' sauberzumachen. Also habe ich den XMX-Wert auf 3/4 des XMS-Wertes gesetzt, und siehe da, seitedem ist das Problem nie wieder aufgetreten. Man kann in der Console auch schön beobachten, dass die 'full GC' beizeiten ausgelöst wird und somit das Problem nicht mehr auftritt.
Mit diesem Wissen habe ich mich dann am Tomcat probiert und auch dort das OutOfMemory-Problem, mit dem ich zuvor lange gekämpft hatte, gelöst.
Wann die 'kleineren Objekte' von der GarbageCollection eingesammelt und zerstört werden hängt also offensichtlich auch von dem Verfügbaren Speicher ab (ist ja auch logisch).

Die Problematik mit den Threadsicheren HTTP-Connections ist mir grade im Domino-Umfeld gut bekannt. (Hängende HTTP-Requests, die das herunterfahren des Servers verhindern). Da hat der Commons.HTTPClient wirklich eine Lücke geschlossen.

Aber es gibt da offensichtlich noch andere Probleme mit dem Thread-Handling. So passiert es mir unter großer Last immer wieder mal, dass die JVM (mit JAVA-API Zugriffen) wegraucht. Im hs_pid stehen dann auch so Thread-Geschichten, die auf Memory-Leaks hinweisen, welche beim Aufruf der Thread.stop()-Methode entstehen. Diese Methode wird allerdings aus den API-Klassen (NotesThread.stermThread()) selbst aufgerufen.


@Ralf
Dass das recyclen der Session auch alle daraus instanziierten Objekte mit-recycelt ist mir neu. Aber gut zu wissen.

Thomas

[flaite]

Hallo Thomas,

es ist schon richtig, dass man mit diesen Parametern tunen kann. Eine wirklich 100% zuverlässige Kontrolle über den garbage collector hat man aber nicht. OutOfMemoryExceptions können auch als Hinweis auf eine unsaubere Stelle im Code angesehen werden.
Notes Zugriffe haben bestimmt noch ein paar Rätsel. Wir haben hier z.B. gerade das Problem, dass ein im debug Modus gestarteter JBoss Exceptions wirft, die er im normalen Modus nicht wirft. Und das wird von Notes-Klassen geworfen.

Gruß Axel

[Snowaddy]

Seid Notes 4.x habe ich schon ein Problem mit Java Applets in Notes Dokumenten.
Im Web funktioniert alles wunderbar (SUN JVM etc.)
Im Notes Client jedoch summiert sich der Speicherverbrauch des Notes-Tasks mit jedem Öffnen des Dokumentes, das das Applet enthält.
Das Applet ist ca. 300KB groß, lädt relativ viel nach und erzeugt auch sehr viele Objekte..
-> Einmal Öffnen kann schon mal 5MB verbrauchen.

Diese werden aber nach dem Schließen nicht wieder zur Verfügung gestellt.
Gegen Ende der Fahnenstange (JavaMaxHeapSize erreicht) wird Notes dann langsam und bleibt schließlich hängen.

Man kann natürlich in der notes.ini JavaMaxHeapSize hoch setzen. Aber das kann doch nicht die Lösung sein...

Außerdem habe ich den Eindruck, dass das Ablegen der Applet-Klassen lokal auf dem Rechner und setzten des Pfades (JavaUserClasses) in der notes.ini etwas hilft...

Woran kann das liegen ?

Wie gesagt: Mit SUN JVM funktioniert alles ohne Probleme.

Gruß, Dirk.

[Ralf_M_Petter]

Verwendet das Applet das Notes API?

Grüße

Ralf

[Snowaddy]

Ja, schon..

Die werden aber alle recycled. Bei der Session bin ich mir nicht ganz sicher...

[Ralf_M_Petter]

Ohne den Code jetzt zu sehen, werden wir da auf keinen grünen Zweck kommen. Versuche einen Testcase zu gernerieren, der so einfach wie möglich ist, bei dem das Problem jedoch noch auftritt. Dann poste den Source dazu dann schau ich mal kurz rein.

Grüße

Ralf

P.S. Bei Applets muß man wie bei allen Gui Sachen extrem auf das Threading aufpassen. Vor allem auf die NotesThread.sinit und term Problematik.

[Snowaddy]

Hier einige Code-Schnipsel für das Laden der Daten :


                // Session holen
      try {
         session = openSession();
      } catch (NotesException e) {
         e.printStackTrace();
      }

                // DB usw. öffnen
      try {
         Database db = session.getDatabase(model.dbServer, model.dbPath);
         Document document = null;
         if (model.doc != null)
            document = db.getDocumentByID(model.doc);
         else
            document = db.getDocumentByUNID(model.docUNID);
                        // Daten laden
         ladeDaten (db.getParent(), document);
      } catch (Exception e) {
         e.printStackTrace();
      }



   public void ladeDaten(Object session, Object doc) {
      Database    db = ((Document)doc).getParentDatabase();
      View        view = db.getView(name);
                //....
                //(Kein NotesThread.sinit() oder sterm().....)
                //........
                if (view != null)
          view.recycle();
      if (db != null)
          db.recycle();
                //..........
                // Kein session.recycle
        }



Kann das fehlende session.recycle denn die Ursache sein ? Es werden ca. 100 kb Daten geladen. Aus denen werden dann viele Objekte erzeugt, die nichts mit der Notes-API zu tun haben. Der Speicherverbrauch deutet eher darauf hin, dass diese Objekte nicht wieder aufgeräumt werden.

Wo muss ich mit dem Threading aufpassen ?

[Ralf_M_Petter]

Ohne Böse zu sein, aber deine Code schnippsel sagen praktisch gar nichts aus. Gerade bei so vertrakten Problemen wie Memory leaks, benötigt man auf jeden Fall den gesamten Code der das Problem auslöst, sonst ist das nur ein Blick in die Kristallkugel.

Also mein Tip. Mach dir die Arbeit und mach ein einfaches Beispiel mit so wenig Code wie möglich wo du den Fehler reproduzieren kannst.

Verwendest du Swing in deinem Applet? Eventuell sind es deine Swing Objekte die sich irgendwie gegenseitig referenzieren. in dem Bereich hatte ich schon mal Probleme.

Grüße

Ralf

[Snowaddy]

Vielen Dank für Deine schnellen Antworten..

Ich kann kaum die ganzen 300kb Code posten (Source-Code noch viel mehr). Der gepostete Code beschreibt grob das Laden der Daten...

Wieso muss ich mit NotesThread.sinit/sterm aufpassen ? Muss ich diese überhaupt verwenden (es funktioniert ja auch so) ?

Kann es sein, dass Objekt von der Notes-JVM nicht wieder freigegeben werden ?

Danke, Dirk.

[Ralf_M_Petter]

Drum habe ich ja gesagt, du sollst ein kurzes Beispiel machen bei dem das Problem auch auftritt. Das ist die normale Vorgehendsweise bei solchen Problemen. Das Applet soweit wie möglich zu reduzieren.


Zu NotesThread.sinit sterm ist zu sagen, wenn du die Notes API nur im Standard Thread verwendest, wirst du es nicht brauchen. Wenn du es jedoch auch z.B. im Event Handler Thread verwenden willst, dann musst du diesen Thread unbedingt für Notes initialisieren und auch wieder beenden. Man sollte auch nicht Notes Objekte in mehreren Threads verwenden. Vorsicht, das gilt aber nur bei Verwendung des lokalen Zugriffs. Wenn du DIIOP verwendest was im Webbrowser wahrscheinlich so ist, darf man NotesThread nirgends verwenden. In Notes wird aber sehr wohl der Lokale Zugriff verwendet.

Aber wie gesagt ohne vollständigen Code ist alles Kaffeesudleserei.

Grüße

Ralf

[Snowaddy]

Ok, danke für die Hilfe.

Ich werde jetzt nicht alle 20000 Codezeilen posten..

Was ich nur traurig finde ist, dass sich der Notes Client verabschiedet, sobald der Java Speicher am Ende ist..

Es liegt mit Sicherheit auch nicht an der Benutzung der Notes-API.
Es mag sein, dass nicht alle Objekte beim Beenden sauber auf NULL gesetzt werden, aber es sollte doch auch ohne das explizite Setzen auf NULL funktionieren.
Tut es ja in anderen JVMs auch.

Gruß, Dirk.

[Ralf_M_Petter]

Entschuldige kannst du mir vielleicht sagen was an dem Satz "Du sollst ein einfaches Beispiel bringen wo das Problem auftritt" du nicht verstehst? In einem 20000 Zeilen Code Monster wirst du den Fehler sowieso nie finden. Deshalb ist wie ich bereits mehrmals geschrieben habe die richtige Vorgehendsweise bei solchen Problemen den Fehler mit einem einfachen Beispiel zu reproduzieren.

Meiner Erfahrung nach liegt es meistens daran dass man in Swing nicht ordentlich aufgeräumt hat. Ein Teil deines Applets läuft dann nach Beendigung des Codes einfach weiter. Das liegt meiner Meinung auch ein wenig darin begründet, da Notes die JVM nach Beenden des Applets nicht einfach beendet. Notes verwendet auch nur eine JVM für alle Aktivitäten.

Wie gesagt, helfe gerne aber wenn du dafür nichts machen willst, wendest du dich wohl besser nicht an ein Forum sondern an den kostenpflichtigen Support. Leider für dich werden die auch ein Beispiel anfordern an dem das Problem reproduzierbar ist.

Grüße

Ralf

[flaite]

Was ich nur traurig finde ist, dass sich der Notes Client verabschiedet, sobald der Java Speicher am Ende ist..

ich nicht. Ich glaub das wäre eventuell eine Sicherheitslücke, wenn das nicht so wäre. Die JVM ist so spezifiziert, dass sie diesen Error (nicht Exception) werfen muß.

Du kannst es mal mit Profiling Tools versuchen.
Wir arbeiten aber auch noch daran, dieses Thema einigermassen stabil und nicht chaotisch in den Griff zu kriegen. Es gibt in diesem Bereich immer mehr, bessere und komfortablere Tools. Leider sind die besten nicht umsonst.
Vielleicht poste ich mal was dazu.

Gruß Axel