Error cleaning up agent threads und WeakReference...

[Mark³]

Ich nutze Java-Agenten in Notes, um auf HP Openview Service Desk mit der web-api zuzugreifen. Für diejenigen, die Openview nicht kennen: Mittels der web-api erzeuge ich ein Objekt vom Typ ApiSDSession, mit welchem ich alle Aktionen im Openview Service Desk ausführen kann. Der Server dazu steht irgendwo im WAN.

Der Fehler 'error cleaning up agent threads' entsteht dadurch, dass ein Notesagent andere Threads startet und beim Beenden nicht weiß, ob die anderen Threads alle ebenfalls beendet wurden. Das Objekt ApiSDSession hat die Methode closeConnection(), womit die Verbindung zum Openview-Server beendet wird. Nun kann man das Objekt auf null setzen und alles ist im Lot. Nur merkt Notes das leider nicht.
Bei Notes.net gibt es eine Technote, um den Fehler einzugrenzen. Dafür sammelt man alle Threads aus der Threadgroup, in der der aktuelle Agent läuft. Normal findet man zwei Threads, die beide zum Notesagenten gehören. Bei mir finde ich 4 Threads, zwei haben den Namen 'WeakReference Plumber' die wohl zu dem Openview-Objekt gehören.
Zu WeakReference habe ich in einer Javadokumentation gefunden, dass solche Objekte ruhig garbage collected werden können auch wenn  man nicht sicher ist ob sie ordentlich finalisiert wurden (ich bin hier nicht so der Experte auf diesem Gebiet). Scheinbar hilft Notes das nicht.
Wenn ich diesen Agenten nun mehrmals hintereinander aufrufe bekomme ich einen Speicherüberlauf in der JVM (die DB liegt auf dem Server, den Agenten starte ich über einen Button in einem Dokument). Dies scheint aber nur bei unseren 6.03-Installationen aufzutreten. Beim 6.54 bekomme ich zwar auch den '...cleaning up...'-Fehler in der Konsole, aber keinen Speicherüberlauf. 

Habt ihr noch Ideen, wie ich das umschiffen könnte? Die web-api.jar (und auch die anderen Java-Klassen) nutze ich übrigens, indem ich alle Klassen in Eclipse entwickle und als Notes Agent mit Imported Java ausführe (keine Einträge in der Notes.ini oder so)

Jede Anregung willkommen...

[flaite]

keine konkrete Lösung.
Der Begriff WeakReferences wird meistens für konstrukte wie folgt gewählt ->
Ein Objekt ist eligible for garbage collection, wenn keine Referenzen aus anderen Objekten auf dieses Objekt mehr existieren.
Manchmal ist es wünschenswert, dass Objekte auch dann eligible for garbage Collection sind, wenn sie noch in bestimmten Container-Objekten wie Maps referenziert werden (z.B. ist WeakHashMap eine konkrete Implementierung davon). Das Objekt muß dann selbst in eine WeakReference gewrappert werden. 
Verdammt viele googles gegen solche weiterführende Java-Geschichten landen übrigens immer in der gleichen Quelle:
http://javaalmanac.com/egs/java.util/coll_WeakMap.html

Idee: Vielleicht kannst du selbst die Objekte auf Null setzen, die von WeakReferencePlumber referenziert werden? Oder dir zumindest per Debugger oder ähnlichem einen Überblick zu verschaffen.

Deine Idee mit Imported Java könnte eventuell zu den OutOfMemoryException führen.
Kannst du die in Eclipse entwickelten Klassen nicht einfach in ein jar packen und dann in lib/ext der VM? Wenn das zu Deployment Problemen führt, weil das lokale Agenten sind, kann man das evtl. über Mails verteilen. Wir hatten solche OutOfMemories wenn ich mich recht erinnere auch z.B. wenn JDBC Treiber an den Agent gehängt wurden statt sie in UserClasses oder in java/lib/ext zu tun.

Gruß Axel

[Ralf_M_Petter]

Hallo Mark!

Zusätzlich zu dem was Axel schon so gut erklärt hat. Sehr häufig werden Weakreferences für Cache Kostrukte hergenommen und sollten eigentlich verhindern, dass der Cache den Speicher sprengt. Aber etwas anderes, ich mache eigentlich kaum noch diese Java Agent Sachen, da es mir einfach zu wenig stabil ist (Lotus sollte da wirklich mal was tun). Ausserdem ist halt JDK 1.3.1 mittlerweile schon ein wenig fad. Ich habe beste Erfahrung gemacht, dass ausserhalb des Domino Servers in einer eigenen JVM zu betreiben. Das läuft mit wesentlich besserer Performance da bessere JVM und man hat wesentlich weniger Probleme mit den ganzen Besonderheiten von Notes. Also einfach mal den Agent in ein externes Programm auslagern und das ganze kann ja dann auch über ein Programmdokument bequem zeitgesteuert vom Server aufgerufen werden.

Grüße

Ralf

[flaite]

Mark,

beide von dir geschilderten Probleme sind im Prinzip Plattform-Probleme. Genauer Plattform-Probleme der Java Runtime in Notes.
Das Problem ist, dass die Designer der Plattform Java in Notes diese Probleme nicht vorhergesehen haben. Genau das ist die Wurzel aller "Java isn't very well implemented in Lotus Notes"-Diskussionen.

Plattform-Probleme treten überall auf.
Z.B. sollte man mal versuchen einen Ankerlink innerhalb von Jsr-168 Portlets zu programmieren. Es ist deutlich schwerer als man denkt und am Ende habe ich es ohne Ankerlink programmiert.

Der Grund?

All the decisions, all the architecture, all the languages, the tools, the databases, the protocols, the hardware, they are all the way they are because we zigged instead zagged.

http://damienkatz.net/2006/03/my_new_favorite_1.html

Bei Plattformproblemen entstehen sehr oft unabsehbare Kosten. In Notes-Java gibt es  eine Menge dieser Issues. Vermutlich dauert deshalb die Eclipsierung von Notes so lange. In Java Plattformen (J2EE-basiert, Kombinationen von OS-Frameworks, Eclipse, etc) gibt es diese spezifische Häufung von Problemen nicht. Probleme - d.h. Aufgabenstellungen, die sich als deutlich komplexer herausstellen als man erst denkt, gibts natürlich überall.

Was ich eigentlich sagen will: Um das WARUM dieser 2 gemeldeten issues zu ermitteln, muß man vermutlich wirklich tief buddeln. 

Gruß Axel

Axel

[Mark³]

Vielen Dank für die Hinweise, scheinbar ist Notes so nicht in der Lage mit imported java umzugehen.
Einige Anwender bekommen auch die Fehlermeldung:

Code

JVM: Attempt to retrieve Java agent attachments failed

Die jar für Openview ist 3.7MB groß, das ist bestimmt nicht gut, die im Agenten zu importieren.
Ich denke, ich muss die Openview-Logik auf dem Server zentralisieren und die Aktionen der Anwender dann asynchron verarbeiten. Wo sollte die große jar-Datei dann liegen, auf dem Server mit JavaUserClasses in der Notes.ini (bzw. Configuration-Dokument) oder geht es auch als Skriptlibrary in der Datenbank?
@Ralf: Wenn ich eine eigene VM für das Programm nehmen würde, wie würde ich das dann einbinden? Per Programmdokument kann ich das ja nicht ereignisgesteuert laufen lassen, oder? TriggerHappy von Damien Katz könnte ich als Trigger nehmen aber das erscheint mir irgendwie zu krumm...

Vielleicht habt ihr noch ein paar Ideen, wenn ich die Anforderung konkretisiere: Ich verwalte in der Notesdatenbank Empfangsbestätigungen für Hardware, die dann digital signiert werden. Der jeweilige Zustand der Bestätigung muss dann mit Openview synchronisiert werden.

[Ralf_M_Petter]

Die Ereignissteuerung ist ebenso kein Problem, du reduzierst deinen Agenten mit den richtigen Triggern einfach auf einen shell Command in dem du die externe JVM mit deinem Java Code aufrufst. Sollte normalerweise kein Problem sein.

Jetzt mal zu deiner konkreten Anforderung. Leider schreibst du nicht, wieviele Transaktionen so bei deinem System laufen. Falls es viele sind, würde es sich eventuell lohnen, dass dein Java Programm permanent läuft. Und du könntest es ja dann so programmieren, dass es auf einen Socket horcht und von dort die Notes ID der zu verarbeitenden Dokumente annimmt. Dann sparst du den großen Overhead des Starts der JVM und ausserdem würde dein Programm vom JIT Compiler besser compiliert. Eventuell könnte man es auch mittels Webservices realisieren.

Grüße

Ralf

[flaite]

dass dein Java Programm permanent läuft.

... und genau hier könntest du über Java RMI nachdenken, weil es vermutlich einfacher ist (ist es wirklich).
Oder vielleicht auch Webservices.
Bzgl. Socket
Die de.comp.lang.java Legende Stefan Matthias Aust hat hier ein kurzes 3-teiliges Beispiel wie man -sagen wir - etwas in Java programmiert, dass auf ein Socket horcht. Ein Webserver. Ist sehr ähnlich.
http://groups.google.de/groups/search?hl=de&q=Do+it+yourself+webserver&qt_s=Suche

[Mark³]

Ich habe so etwa 100 Transaktionen pro Tag.
Ich hatte ja bereits mal einen RunJava-Task auf meinem Server laufen, das lief eigentlich sehr gut. Vielleicht sollte ich den Laufen lassen und dort alle Verbindungen von allen meinen Datenbanken zu Openview bündeln. Allerdings ist das irgendwie nicht so wartungsfreundlich und auch nicht modular.
Ich werde mal die verschiedenen Modelle durchdenken. Übrigens läuft der Server auf 6.54, bald aber auf 7.01, da ist die VM vielleicht ja wieder etwas schneller!?

[flaite]

Java als Plattform besitzt genug Remoting-Mechanismen, mit denen man das
a) stabiler
b) skallierbarer
c) wartbarer
d) auditierbarer
e) sicherer
f) transparenter
g) übersichtlicher

durchführen kann.
RMI, Server-Prozess oder Webservices. Es ist nicht so schwierig.

[Ralf_M_Petter]

Meiner Meinung nach, würde es sich bei 100 Transaktionen sicher schon lohnen, den Task den ganzen Tag laufen zu lassen. Ich finde gerade die externe Programmierung viel wartungsfreundlicher, da ich dann den Java Code in einer vernünftigen Entwicklungsumgebung habe und nicht immer in den Designer einkopieren muß.

Grüße

Ralf

[Mark³]

ok, ich versuche mal, das bisher Gesagte zusammenzufassen:

• Die Transaktionen mit Openview werden in einer einzigen Java-Anwendung gebündelt, die außerhalb der Domino JVM läuft
• a) Die Transaktionen werden entweder per Shell-Befehl gestartet (Nachteil: viel Overhead durch häufige Starts der Anwendung) oder b) die Anwendung selbst überwacht aktiv eine/mehrere Domino-Datenbanken oder c) die Anwendung läuft ständig und wird über RMI oder SOAP angesprochen
• Der Vorteil bei c) wäre natürlich, dass ich synchron eine Antwort erhalten könnte. Ich würde also per Notes-Java-Agent remote auf meine Openview-Mittelschicht zugreifen und könnte die Ergebnisse direkt in mein DocumentContext einfließen lassen.

Die Lösung c) würde ich anpeilen, ich weiß allerdings nicht, ob ich dann wieder mit 'Error cleaning up agent threads' zu kämpfen habe.
Und ein eigenständiges Java-Programm, welches andauernd läuft, wie sähe das aus? Nimmt man da einen Service (Windows!) ? Oder kann ich es so wie im Webserver-Beispiel realisieren? Da fehlt mir leider die Übersicht...

[Mark³]

noch ein Nachtrag für Openview-Nutzer: Die Web-Api dient eigentlich dazu, Openview per JSP anzusprechen, daher läuft bei den meisten Installationen auch bereits ein Web Application Server auf dem Openview-Server mit. Leider kann ich diesen aber aus organisatorischen Gründen nicht nutzen und dort direkt Webservices programmieren...

[Ralf_M_Petter]

Ich weiß jetzt nicht, was du für ein Websever Beispiel du meinst. Aber prinzipiell würde Lösung c so wie du es beschrieben hast funktionieren.

Grüße

Ralf

[Mark³]

das Beispiel aus Antwort #6 von Axel meinte ich...
Mir fällt noch ein, dass ich schon mal testweise einen Tomcat aufgesetzt hatte um JSP zu nutzen. Die Programmierung war mir da zu umständlich, aber vielleicht kann ich auf dem Tomcat ein paar Webservices implementieren...Allerdings wäre mir die eigenständige Java-Anwendung lieber, da ich dann nicht noch zusätzlich den Tomcat warten müsste.
Das Problem an der ganzen Sache ist wie so oft, dass sie keine Zeit kosten darf (und damit auch kein Geld). Ist natürlich nicht ganz zu erreichen, aber die Lösung mit dem wenigsten Aufwand gewinnt, nicht die mit der besten Umsetzung...

[flaite]

rmi könnte das einfachste sein. Ich kann mich heute abend mal mit Domino 7 dran probieren.
Länger nicht mehr gemacht, aber afaik geht das auch über http getunnelt (falls offene Ports ein Problem darstellen).
In der Java Develloper (nicht Programmer) Zertifizierung (die ich nicht habe) wird das Programmieren eines Remoting-Beispiels gefordert. Da kann man zwischen Socket und RMI auswählen. Machbar ist das auf jeden Fall. Imho auch in einem wirklich vertretbaren zeitraumen.
Wenn die Anwendung verteilt über das Netzwerk geht, gibts natürlich eine Menge möglicher Fehlerquellen für einen reibungslosen Betrieb. Das ist aber gut dokumentiert.
Ich denke, ich fang heute abend mal mit einem rmi Beispiel für Domino 7 (hab zu Hause zur Zeit nix anderes, ist btw. relativ egal) an. Sollte ich eigentlich noch können.

Gruß Axel   

[Mark³]

Zwischenstand:
Als Workaround (ITIL lebe hoch) habe ich erstmal die großen jars (Web-api für Openview und Openlog-Funktionen) in eine Java-Lib in der Datenbank gepackt und die Agenten von Imported Java auf Java umgestellt.
Nachteil: Ich entwickle weiterhin in Eclipse, muss den Sourcecode aber in den Notesagenten reinpasten anstatt nur Refresh zu drücken
Vorteil: Bei einem ersten Test schint der Fehler nicjht mehr aufzutreten. Habe in der Debug-Konsole mal mit m einen Memorydump gemacht nach jeweils einer Transaktion. Ergebnis:

1. 84% free
2. 34% free
3. 34% free aber 70k weniger als bei letztem Schritt
4. 34% free aber 70k weniger als bei letztem Schritt
5. 34% free aber 70k weniger als bei letztem Schritt
6. 80% free

Anscheinend läuft der Garbage Collector und erlöst den Client dann vom Speichermüll. Leider bekomme ich aber immer noch 'Error cleaning up agent...' daher möchte ich langfristig auf jeden Fall die Openview-Zugriffe separat in einer vernünftigen VM laufen lassen.
Im Agenten rufe ich zwar auch ein System.gc() am Ende auf, aber das scheint nicht direkt was zu tun sondern eher ein Tip für die VM zu sein, die Garbage Collection eher früher als geplant laufen zu lassen.

[Mark³]

hier noch mal ein paar Details zu meinem Recycling, vielleicht ist hier ja auch ein Wurm drin:

Code

public void NotesMain() {
		oli = new OpenLogItem();
		try {
			session = getSession();
			AgentContext agentContext = session.getAgentContext();
			DocumentCollection dc = agentContext.getUnprocessedDocuments();
			Agent agent = agentContext.getCurrentAgent();
			db = agentContext.getCurrentDatabase();
			profileDoc = db.getProfileDocument("abc", "");
			
			ov = new OVTool();
			if (ov != null) {
				...
				Document doc = dc.getFirstDocument();
				while (doc != null) {
					
					doc = dc.getNextDocument();
				}
				ov.disconnect();
				ov = null;
			} 

			profileDoc.recycle();
			db.recycle();
			agent.recycle();
			agentContext.recycle();
			session.recycle();
		}

		catch (Exception e) {
			oli.logError(e);
			System.gc();
		}
		oli.recycle();
		System.gc();
	}

Und noch ov.disconnect() im Detail:

Code

public void disconnect()  {
		oli.recycle();
		s.closeConnection();  //beendet die Openview Session
		s = null;

	}

In meiner Iteration der DocumentCollection könnte ich noch ein tempDoc deklarieren und damit bei jedem Durchlauf das momentane doc recyclen (habe ich bei notes.net als aggressives oder so ähnlich Recycling gesehen aber der Sinn hat sich mir nicht erschlossen da das Recyclen der DocumentCollection doch eigentlich auch alle docs mitnehmen sollte, die dadrin sind, oder? Gleiches müsste dann natürlich auch für die db und die session gelten. Ist also alles nicht 100%ig verstanden von mir...

[Ralf_M_Petter]

Das recycle läuft falsch.

Grundregel: Nur Dokumente recyceln, die du selber erstellt hast. Also auf keinen Fall die Session und den AgentContext recyceln.

Für was du das Objekt agent brauchst entzieht sich ebenfalls meiner Kenntnis. Komisch ist auch die Zeile oli.recycle(). Ist da auch ein Notes Objekt?

Übrigens das mit dem Cleaning up agent Threads ist ja eigentlich keine Fehlermeldung im eigentlichen Sinn, sondern nur ein Hinweis, dass Threads gekillt wurden, die dein Code nicht ordnungsgemäß abschgeschlossen hat. Eventuell solltest du mal deinen OpenView Code in einem Debugger laufen lassen und schauen welche Threads da überbleiben und ob die eine Möglichkeit bieten das zu beenden. System.gc muß nicht aufgerufen werden, vor allem nicht in einem Server.

Zum recyceln in der Schleife, das sollte man auf jeden Fall machen. Wenn die Schleife nur ein paar mal durchlaufen wird, hast du sicher noch kein Problem. Wenn die Schleife jedoch 1000te mal durchlaufen wird, dann bekommst du garantiert ein Memory Problem. Also in Schleifen das Doc immer nach Verwendung recyclen.

Die Document Objekte werden erst beim GetNextDocument erstellt. Was aber stimmt, ist das alle Dokumente die noch nicht recycelt waren beim Recyceln der DC mitgenommen werden. Aber bis dahin kann schon OutOfMemory aufgetreten sein.

Grüße

Ralf

[Mark³]

es ist immer schön, mal wieder was dazuzulernen 
Die Recycling-Geschichte werde ich nochmal aufgreifen.
Zu oli: das ist das OpenLogItem (OpenLog von openntf.org), für mich gehört das schon selbstverständlicherweise in jede Datenbank rein. (Ich hatte es zum Testen mal komplett rausgelassen, hatte aber keinen Einfluss auf den cleaning up-Mist).
Das agent-Objekt nutze ich, um den Namen des Agents ins Log zu schreiben, ist natürlich Blödsinn, weil das Log sowieso den Namen automatisch logged...

Was sagst du dazu?

Code

public void NotesMain() {
		oli = new OpenLogItem();
		try {
			session = getSession();
			AgentContext agentContext = session.getAgentContext();
			DocumentCollection dc = agentContext.getUnprocessedDocuments();
			db = agentContext.getCurrentDatabase();
			profileDoc = db.getProfileDocument("setup", "");
			ov = new OVTool();
			if (ov != null) {	
				Document doc = dc.getFirstDocument();
				Document temp = null; 
				while (doc != null) {
					...
					temp = dc.getNextDocument(doc); // get the next one
					doc.recycle(); // recycle the one we're done with
					doc = temp;
					
				}
				ov.disconnect();
				ov = null;
			}
			profileDoc.recycle();
			db = null;
			agentContext = null;
			session = null;
		}

		catch (Exception e) {
			e.printStackTrace();
			oli.logError(e);
			
		}
		oli.recycle();
		
	}

[Mark³]

das geänderte Recycling erlöst mich leider nicht vom cleaning up-Krams. Das liegt wohl wirklich daran, dass Notes die Openview-Geschichte nicht richtig entsorgen kann.
Leider tritt auch der Speicherüberlauf immer noch auf. Bei mir läuft das alles aber bei einem Kollegen trat er wieder auf, obwohl ich nun die jars in eine lib gepackt habe (und vor erneutem Testen die cache.ndk gelöscht habe).

Also doch eigenständiges Java-Programm mit RMI oder sowas. Leider weiß ich noch nicht so richtig, wo ich damit starten soll. Mal sehen, ob Axel was mit Notes 7 und RMI rausfindet, ansonsten werde ich wohl erstmal etwas Literaturrecherche betreiben müssen.
Im Prinzip brauche ich ja nur ein Javaprogramm, welches im main() in einer Endlosschleife auf irgendwelche Ports oder Sockets hört und dann für jeden Aufruf einen Thread laufen läßt, welcher eine Openview-Transaktion durchführt und ein paar Daten zurückmeldet, die ich wieder über Socket an den Caller zurückgebe.