LS2J Schnittstelle - memory leak

[Manfred Dillmann]

Hallo Axel,

zu Deinem Stichwort "memory leak" aus Deinem letzen Post:

Ich hatte bei meinem RSS Reader ein ebensolches Problem - obgleich ich keine Domino-Objekte verwende. Nach ca. 100 Läufen des Agenten auf dem Domino Server war mit dem Fehler:

Agent 'Fetch News Background' error: LS2J Error: Threw java.lang.OutOfMemoryError

dann Schluss.

Übliche Dinge wie Objects auf null setzen und System.runFinalization(); bzw. System.gc(); (war ein Tipp auf meine Frage im notes.net 6er Forum) haben etwas Linderung gebracht - richtig geholfen hat das alles aber nicht.

Nach vielen weiteren vergeblichen Versuchen habe ich dann versucht, statt einer Übergabe der Parameter( urlToLoad, ...) und der Rückgabe (return bufResult.toString() die Funktion in der folgender Form zu gestalten:

public class GetRSSFeed {
   
   public String urlToRead;
   public String proxySet;
   public   String proxyHost;
   public   int proxyPort;
   public   String proxyUser;
   public String proxyPassword;
   public String returnURLContent;
   
   public void getRSSFeed() {
   ...
   returnURLContent = bufResult.toString();
   return;
   }
}

Ich setzte und lese dann diese Properties via LS (zwischendurch natürlich den Aufruf der Function). Ergebnis: der Agent läuft jetzt bei mir seit nahezu 2 Tagen non stop im 5 Minuten Takt ohne Speicherprobleme.

Axel, hast Du einer Erklärung ob das ein BUG in der Implementierung der LS2J Schnittstelle sein kann oder ob es daran liegen könnte, dass "String" in Java keiner der primitiven Datentypen ist?

P.S.
Mein RSS Reader funktioniert jetzt prima - offensichtlich auch durch eine Firewall - das wolltest Du mal in einem früheren Post wissen - kannst Du jetzt ja mal testen...

Gruss
Manfred

[Axel_Janssen]

Hallo Manfred,

erstmal Glückwunsch zur Ausschaltung des Störfeuers.

Ich habe mich noch nicht mit LS2J beschäftigt. Wenn ich mit Java in Lotus arbeite ist es bislang immer pur-Java (etwa ein Agent, 1 Applet, 1 GUI, die von aussen zugreift).
Du hast da einen interessanten Punkt aufgebracht. Und das ist leider wieder so ein Ding, wo offenbar etwas nicht so sauber von Lotus implementiert bzw. dokumentiert wird.

Durch

Code

return bufResult.toString() 

wird ein Objekt erzeugt, dass den von der JavaVM verwalteten Heap Speicher belegt. Genau gesprochen ist es ein anonymes, lokales Objekt, da es von keiner Referenzvariable gehalten wird und Methoden-scope hat (keine Instanzvariable in ersten Version).
In einem reinen Java Programm würde das keine Probleme machen. Nach dem return der Methode wäre das Objekt eligible for garbage collection und der entsprechende Speicher würde zu einem geeigneten Zeitpunkt vom Garbage Collector freigegeben. Hmm genau gesprochen kann aus dem aufrufenden code das Objekt gehalten werden. Aber das ist in der Regel kein Problem... Arbeite später an umfangreicheren Erklärung...

Offenbar hält aber LS2J aus für mich derzeit nicht nachvollziebaren Gründen eine Referenz auf ein Objekt, das von einer Methode zurückgegeben wird, die einen nicht-void, nicht-primitiv-Datentyp (int, fload, boolean, etc.) besitzt. Solange eine Referenz auf das Objekt gehalten wird, ist es nicht "eligible for garbage collection".  

Du hast den richtigen Weg gefunden. Du schreibst den String einfach in eine Instanz-Variable, die du pro Durchlauf überschreibst.

Beispiel:
1. Durchlauf:
after completion method void getRSSFeed():
Object-Instanz-Variable GetRssFeed.returnURLContent hält String-Objekt "foo".
2. Durchlauf:
after completion method void getRSSFeed():
Object-Instanz Variable GetRssFeGetRssFeed.returnURLContent verliert Referenz auf String-Objekt "foo" und hat neue Referenz auf neues String-Objekt "bar". Das String-Objekt "foo" ist eligible for Garbage Collection. "bar" wird referenziert.
usw.  


Da der von der Java Virtual Maschine verwaltete Heap Speicher nicht mehr volläuft, schlägt der Java Garbage Collector in der neuen Version offenbar irgendwann zu.  

Sierra/Bates Buch hat sicher ein Kapitel zu den Grundlagen von Java Garbage Collection  

Das hört sich alles komplizierter an als es ist.
Noch was: Bei Methoden mit void-Rückgabe benötigst du kein return. Das letzte return in der Methode kannst du entfernen.

Wie du weisst gibt es keine dummen Fragen, wenn du noch Fragen hast.

Ein anderer Weg wäre vielleicht mit einem Singleton zu arbeiten (später mehr).  

Gruß Axel

[Axel_Janssen]

Ein anderer Weg wäre vielleicht mit einem Singleton zu arbeiten (später mehr).  

Hmm. LS2J behandelt das Objekt der Klasse GetRSSFeed offenbar als Singleton. Du erzeugst ja aus dem code immer neue Objekte der Klasse GetRSSFeed. Nur ist LS2J offenbar so schlau, dass es immer das selbe Objekt wiederverwendet. Sonst würde das mit dem Überschreiben der Instanzvariable returnURLContent so gar nicht funktionieren.

Dann wären nämlich mehrere Objekte vom Typ GetRSSFeed im Heap und es würden keine Instanz-Variablen überschrieben.

Singleton ist ein Design-Pattern, das benutzt wird, wenn man von einer Klasse genau 1 Objekt haben will.

Es wird so implementiert:

Code

public class ASingleton {

// Klassenvariable. An Klasse nicht Objekt gebunden (static)
private static final Elvis INSTANCE = new Elvis();

// Konstruktor ist private. Kann nur aus Klasse selbst aufgerufen werden, nicht von aussen
private Elvis() {}

// das kann von aussen angesprochen werden. Gibt aber immer den selben Elvis zurück
public static Elvis getInstance() {
return INSTANCE; 
}
}

wenn man in der Klasse mit Objekt-Serialisierung arbeitet, sind weitere Sachen zu beachten.

Übrigens kannst du deine Methode getRSSFeed() vielleicht auch als static-Methode implementieren und weiter mit String-Rückgabewert arbeiten.

Gruß Axel

[Manfred Dillmann]

Hallo Axel,

danke für Deine Ausführungen - verstehe mal wieder nicht alles, aber das wird schon...

>>erstmal Glückwunsch zur Ausschaltung des Störfeuers.<<

Ja, da habe ich mich wirklich gefreut. Zumal auf meine Frage im 6er notes.net Forum nicht mal ansatzweise ein Lösung kam. Habe dort aber heute meinen Weg gepostet (meine Frage war am 14.01 wenn Du´s dort mal lesen möchtest).

Du schreibst:
>>LS2J behandelt das Objekt der Klasse GetRSSFeed offenbar als Singleton. Du erzeugst ja aus dem code immer neue Objekte der Klasse GetRSSFeed. Nur ist LS2J offenbar so schlau, dass es immer das selbe Objekt wiederverwendet. Sonst würde das mit dem Überschreiben der Instanzvariable returnURLContent so gar nicht funktionieren.<<

Nö, mache ich nicht. Es wird nur EIN Object erstellt und immer wieder referenziert. Das sieht in LS so aus:
Dim js As JavaSession
Set js = New JavaSession
   
Dim getRSSFeedClass As JavaClass
Dim getRSSFeedObject As JavaObject
   
Set getRSSFeedClass = js.GetClass("GetRSSFeed")
Set getRSSFeedObject = getRSSFeedClass.CreateObject ' 1x Object erstellen/instanzieren
...
' Properties wie URL, Proxy usw. setzen
...
Call getRSSFeedObject.getRSSFeed() ' Aufruf mit IMMER gleichem Object in einer Schleife
Set jProperty = getRSSFeedClass.GetProperty("returnURLContent")
html = jProperty.GetValue( getRSSFeedObject )

Da ist LS2J wohl doch nicht so schlau...?

Vielleicht noch was für den Java-Crack zum schmunzeln, ich selbst kann mir das auch nicht richtig erklären:
Ich hatte ja aus lauter Verzweiflung alles mögliche probiert und bin noch auf den folgenden Effekt gestossen, vielleicht hast Du dafür eine Erklärung?

Als ich statt:
return bufResult.toString()

das hier:
String URLContent = bufResult.toString();
return URLContent;

verwendet hatte, war die Laufzeit des Agenten schon mindestens doppelt so lange wie vorher. Für einen Moment dachte ich, das wäre schon die Lösung, hat aber den Tot nur etwas verzögert...

Gruss
Manfred

[Axel_Janssen]

Die ganze Geschichte ist ein bischen misteriös.
Es gibt eine reine Anwendungsentwickler-Sicht. Lotus stellt dieses LS2J zur Verfügung und der Entwickler kann nach bestimmten Regeln Java Objekte erzeugen, Methoden aufrufen etc.
In Wirklichkeit gibt es darunter eine systemische Schicht. Von dieser Komplexität soll der Anwendungsentwickler nix merken.
In Wirklichkeit sind das ja Kommunikationen zwischen zwei unterschiedlichen Prozessen. Die JVM läuft in einen anderen Prozess als Notes.
Wie wird jetzt die Connectivity zwischen den beiden Prozessen hergestellt?
Solange ich da keine Texte haben, die LS2J aus einer systemischer Sicht beschreiben, betreibe ich Kaffeesatzleserei.
Manchmal kommt man damit zu Ergebnissen, hier nicht.

Es soll aber nicht der Eindruck entstehen, dass dies Probleme sind, mit denen sich ein Entwickler von Java-Anwendungen normalerweise herumschlägt. Das macht gerade den Reiz aus.

Manfred, die sauberste Lösung wäre vermutlich überhaupt keine Objekte zu erstellen und alles über static abzufackeln (static Instanzvariblen, static Methoden).

Wobei deine Lösung natürlich völlig in Ordnung ist.

Beispiel:

Code

public class AllStatic {

public static String aVar = "hier";

public static String getMsg() {
  return "ist alles static";
}

public static void main (String args) {
System.out.println(AllStatic.aVar + " " + AllStatic.getMsg());
}
}

Es wird kein Objekt instanziiert. Da deine Klasse nur aus einer Methode besteht, könntest du dort genau so vorgehen.

Code

Set getRSSFeedClass = js.GetClass("GetRSSFeed")
' nächstes nicht mehr nötig
'Set getRSSFeedObject = getRSSFeedClass.CreateObject ' 1x Object erstellen/instanzieren
...
' Properties wie URL, Proxy usw. setzen und zwar über getRSSFeedClass.Property="aProperty";
' Methoden-Header in Java: public static String getRSSFeed()
html=getRSSFeedClass.getRSSFeed();

ist total nicht Objekt-orientiert. Da der Java code aber eine genau definierte enge Aufgabe erfüllt, die in Zukunft nicht erweitert werden soll (wüsste nicht warum), ist dies vermutlich die pragmatischste Lösung.

Gruß Axel

Gruß Axel

[animate]

ist total nicht Objekt-orientiert.

das ist aber die derzeitige Lösung auch nicht  

[Axel_Janssen]

ist total nicht Objekt-orientiert.

das ist aber die derzeitige Lösung auch nicht  

Ja gut (und ich habe einen gewissen Respekt vor deiner URL).

Wenn die Anwendung nicht-OO in LotusScript programmiert ist und Java nur als eine Art Erweiterung für Services (http-download) benutzt wird, dann ist die Aufgabe im Grunde zu klein für OO. Find ich.  

Ich hab das auch nur in Gedanken zur Linderung meiner Schmerzen, dass ich hier public Klassen-Variablen propagiere, getippt.  

[Axel_Janssen]

Übliche Dinge wie Objects auf null setzen und System.runFinalization(); bzw. System.gc(); (war ein Tipp auf meine Frage im notes.net 6er Forum) haben etwas Linderung gebracht - richtig geholfen hat das alles aber nicht.

Das mit dem System.gc() soll den garbage collector davon überzeugen zu starten. Das ist aber kein zuverlässiges Mittel. Du kannst den garbage collector nicht wirklich aus Programmcode kontrollieren.

Deine Lösung war schon gut.
Ähnlich geht man beispielsweise oft vor, wenn man Informationen aus parallel laufenden Threads benötigt.

Gruß Axel

[animate]

Ich hab das auch nur in Gedanken zur Linderung meiner Schmerzen, dass ich hier public Klassen-Variablen propagiere, getippt.

und ich nur deshalb, weil ich deinen Vorschlag unterstützen und ein mögliches Gegenargument entkräften wollte

Ja gut (und ich habe einen gewissen Respekt vor deiner URL).

lol. Respekt vor der URL an sich oder vor der Seite. Was ist denn da so respekteinflößend?

[Axel_Janssen]

naja respekteinflössend ist vielleicht nicht das richtige Wort.
Es ist interessant.
Manchmal bin ich sprachlich einfach ein bischen unexakt.  
All diese ganzen Methodologie-Diskussionen.
3 Leute eine Meinung:
Scott Ambler, Lasse Koskela, Ilja Preuss auf Javaranch letzte Woche

auch ein guter Essay (leider nur in Spanisch) und eine total andere Meinung:
http://www.javahispano.org/download/tutoriales/MetodosAgiles.pdf

[Manfred Dillmann]

Hallo Axel und Thomas,

danke für Eure Beiträge!

Von Axel:
>>Manfred, die sauberste Lösung wäre vermutlich überhaupt keine Objekte zu erstellen und alles über static abzufackeln (static Instanzvariblen, static Methoden).<<

Axel, ich werde alle Deine Vorschläge durcharbeiten (verstehe noch nicht so genau alle Unterschiede und muss mich da durch weitere Literatur erst mit vertraut machen).

Ist aber wirklich klasse, dass Du mir so viele Anregungen gibts. Wo ich jetzt "etwas Blut geleckt" habe, wird der Reader ja bestimmt nicht mein einziger Kontakt mit Java bleiben. Vor allem durch Eclipse macht es zwischenzeitlich schon richtig Spass...

Von Thomas (aka potsmoker):
"...ist total nicht Objekt-orientiert."
"...das ist aber die derzeitige Lösung auch nicht"

Ich muss zu meiner Schande zugeben, dass ich mit OO bislang nicht viel am Hut hatte. DAS ist natürlich mein Problem...

Der direkte Kontakt mit Java kam ja mehr aus dem Umstand heraus, dass es mit LS alleine (hattest Du ja selbst mal was dazu geschrieben) aufwendig und ein ziemlicher Krampf ist, das zu machen, was ich für meinen Reader brauche...

Daher war der Einsatz von Java eher Mittel zum Zweck und ich schon so froh, dass es jetzt überhaupt funktioniert.

Ist der Weg auch schlecht, ist es manchmal doch wichtig, was hinten heraus kommt... ;-)

Gruss
Manfred

[animate]

Daher war der Einsatz von Java eher Mittel zum Zweck und ich schon so froh, dass es jetzt überhaupt funktioniert.

Ist der Weg auch schlecht, ist es manchmal doch wichtig, was hinten heraus kommt... ;-)

also meine Aussage, das sei nicht objektorientiert, solltest du keinesfalls als Kritik auffassen! Sondern als Grund dafür, Axels Vorschlag mit einer statischen Methode mal zu probieren (falls deine unerwarteterweise noch mal Probleme bereitet)
Und der Weg ist keinesfalls schlecht, sondern gut (IMHO).

[Axel_Janssen]

Ich muss zu meiner Schande zugeben, dass ich mit OO bislang nicht viel am Hut hatte. DAS ist natürlich mein Problem...

Hi,

das ist auch ein längerer Prozess.
Die heftigen Diskussionen in der Java Community auf Holubs Artikel wie "Setters are getters considered evil" zeigen für mich, dass auch unter Programmierern einer expliziten OO-Sprache (abgesehen von den bekannten aus meiner Sicht mehr akademischen Vorbehalten) grosse Unsicherheit besteht, ob das was sie machen "richtig" objekt-orientiert ist.

Daher war der Einsatz von Java eher Mittel zum Zweck und ich schon so froh, dass es jetzt überhaupt funktioniert.

Ist der Weg auch schlecht, ist es manchmal doch wichtig, was hinten heraus kommt... ;-)

So ist das auch.
Das spannende an diesem ganzen OO-Zeugs ist nur, dass es meine Perspektive ändert, wie ich über Software-Projekte nachdenke. Das ist das spannende.
Nur ist es aus meiner Sicht nicht "natürlicher" oder grundsätzlich "einfacher". Es führt einfach zu flexiblerer, übersichtlichere, erweiterbarere Software und einen Software-Erstellungs-Prozess, der mir mehr Spass macht.
Mit all diesen ganzen Gang of Four, J2EE und oh-das-gibts-auch-noch Design-Patterns ist es eine ziemlich abstrakte Geschichte.
Abstrakt heisst aber nicht unpraktikabel. Es ist praktikabel.

Btw. bauen alle noch-neueren Entwicklungen wie test-first programming, aspektorientierte Programmierung alle auf OO auf.

OO-unterstützende Tools von Firmen wie Gentleware und Rational werden auch immer besser.
Es gibt auch immer bessere Texte, die zunehmend klarer darstellt, wie man OO-mässig vernünftig vorgeht. Bei mir z.B. gerade das "Java Design Patterns Workbook" von ?, "Patterns of Enterprise Application Architecture" von Fowler und eine beta von Evans, "Domain Driven Design".

Was ich eigentlich sagen wollte:

Es ist keine Raketen-Wissenschaft, erfordert aber einen längeren Prozess das wirklich zu beherrschen.



Gruß Axel

[Manfred Dillmann]

Hallo Thomas!

>>also meine Aussage, das sei nicht objektorientiert, solltest du keinesfalls als Kritik auffassen!<<

Thomas, wenn man von einem Thema noch keine richtige Ahnung hat, ist es etwas schwierig, eine Aussage als "Kritik" oder "Anregung" zu unterscheiden. Beides läuft aber letztlich auf das gleiche hinaus: Irgendwas scheint noch nicht so OK zu sein und könnte besser gemacht werden. Ich nehme Kritik (so gut das geht, innerer Schweinehund, kennt jeder) auch nicht persönlich, sondern versuche immer mal zu überlegen, ob da nicht doch was dran ist. Meistens ist das ja auch so...

>>Sondern als Grund dafür, Axels Vorschlag mit einer statischen Methode mal zu probieren (falls deine unerwarteterweise noch mal Probleme bereitet)<<

Hatte ich ja geschrieben. Ich versuche, alle Tipps von Axel zu verstehen und probiere das mit Eclipse auch aus. In diesem konkreten Fall verstehe ich den Ansatz mit der "Static-Geschichte" noch nicht richtig, was da denn der genaue Unterschied ist.

>>Und der Weg ist keinesfalls schlecht, sondern gut (IMHO).<<

Danke! :-)

Gruss
Manfred

[Manfred Dillmann]

Hallo Axel,

eigentlich sollte ich was arbeiten, die Zeit drängt, aber das muss ich heute noch schreiben:

>>Das spannende an diesem ganzen OO-Zeugs ist nur, dass es meine Perspektive ändert, wie ich über Software-Projekte nachdenke. Das ist das spannende.<<

Ich habe zwischenzeitlich ganz heimlich auch schon daran gedacht, in meinem Reader noch viel mehr mit Java zu machen (XML-parsing, die News-Dokumente erstellen usw.). Ich bin mir aber da z.Z. noch zu unsicher. Diese vielen "wenns und aber". Kriege ich jetzt einfach noch nicht hin. Ich muss voher noch mehr lernen und kann ja bei einer späteren Version noch mehr mit Java machen - das reizt einen schon.

Auf der anderen Seite läuft es jetzt mit der Kombination LS2J und Java doch recht gut. Alles, was ich mit LS mache, habe ich vergleichsweise sicher im Griff und wenn das memory leak mich nicht 2 Wochen beschäftigt hätte, wäre ja mein Programm schon lange fertig.

Also bleibt das Grundkonzept jetzt wie es ist - habe schon 1 Lizenz verkauft und ich glaube nicht, dass der Ulrich mit der 1.0 bis zum nächsten Jahr warten möchte... ;-)

Gruss
Manfred

[animate]

Hatte ich ja geschrieben. Ich versuche, alle Tipps von Axel zu verstehen und probiere das mit Eclipse auch aus. In diesem konkreten Fall verstehe ich den Ansatz mit der "Static-Geschichte" noch nicht richtig, was da denn der genaue Unterschied ist.

Der Unterschied zwischen "normalen" Methoden

Code

public String getRSSFeed(){}

und statischen Methoden

Code

public static String getRSSFeed(){}

ist, dass du, um die "normale" Methode aufrufen zukönnen eine Instanz der Klasse benötigst

Code

Set getRSSFeedClass = js.GetClass("GetRSSFeed")
Set getRSSFeedObject = getRSSFeedClass.CreateObject ' 1x Object erstellen/instanzieren
getRSSFeedObject.getRSSFeed()

statische Methoden kannst du ohne eine Instanz aufrufen

Code

Set getRSSFeedClass = js.GetClass("GetRSSFeed")
getRSSFeedClass.getRSSFeed()

[Manfred Dillmann]

Hallo Thomas,

danke! Bleibt für mich zwar immer noch die Frage: Was macht Java selbst anders, wenn das "static" auftaucht - werde ich aber bestimmt im Javabuch.de finden.

Jetzt verstehe ich noch was anderes besser:
Ich hatte beim Lesen in der Designer-Hilfe (LS2J im Kontext: lesen und setzen der Properties) etwas vom Einsatz der "dot-notation" gelesen - man ist ja faul und ich wollte mit:

getRSSFeedClass.proxyPort = 8080;

dieses Property setzen. Da kamm immer der Hinweis auf die fehlende Instanz...

Liege ich damit richtig, dass das statt mit:

public class GetRSSFeed {
   
   public String urlToRead;
   public String proxySet;
   public String proxyHost;
   public int proxyPort;
   public String proxyUser;
   public String proxyPassword;
   public String returnURLContent;
   
   public void getRSSFeed() {
   ...
   returnURLContent = bufResult.toString();
   return;
   }
}

mit

public class GetRSSFeed {
   
   public static String urlToRead;
   public static String proxySet;
   public static String proxyHost;
   public static int proxyPort;
   public static String proxyUser;
   public static String proxyPassword;
   public static String returnURLContent;
   
   public void getRSSFeed() {
   ...
   returnURLContent = bufResult.toString();
   return;
   }
}

funktioniert?

Gruss
Manfred

[animate]

damit liegst du richtig

[Manfred Dillmann]

Hallo Thomas!

>> damit liegst du richtig<<

Prima. Würde ich jetzt zu gerne ausprobieren... aber Du kennst das ja: erst die Arbeit, dann das Vergnügen...

Auch Dir noch einen schönen (Rest-) Sonntag!

Manfred