1. Laut IBM wird die Funktion, JAR's in der NSF zu halten, unterstützt. Ich habe im Rahmen der PMR-Bearbeitung den in der DB verwendeten Java-Agenten beschrieben und bekam als Antwort sinngemäß zurück: Ja, müßte alles so gehen.
Es gibt Aussagen eines hohen deutschsprachigen Lotus/IBM Managers von IBM Asia, dass der Classloader Mechanismus für jars als Attachments von Agenten fundamental broken ist.
Und zwar genau in den Kommentaren dieses Threads
http://www.codestore.net/store.nsf/unid/BLOG-20120103-0527?OpenDocument#DOC_9C21B168 diese Aussage.
What I found in agents: if you have external jars and the agent runs multiple times it starts bleeding memory since a new classloader is instantiated every time.
2. Unsere java.policy Datei sieht tatsächlich so aus. Und zwar überall. Vielleicht ist unser Installations-Package das Einzige auf der Welt, bei dem das so ist... schon möglich. Wie SOLLTE die Datei denn aussehen? Hat Deine java.policy Datei auf den Domino Servern diesen Eintrag nicht?
Du brauchst die java.policy Datei nicht ändern. Auf der ersten Seite des Agenten gibts ein Häckchen, dass Du setzen mußt. Wenn eure java.policy Dateien wirklich überall so aussehen, könnt ihr eure Sicherheit dadurch optimieren, dass ihr sie wieder auf den Ausgangszustand setzt.
3. Wenn JAR's in der NSF liegen, müssen diese für die JVM vor dem Verarbeiten erst im Filesystem abgelegt werden, richtig? Als temporäre Datei? Oder wird die Ressource zur JVM quasi "gestreamt"?
Solche Details haben mich nie interessiert. Mir reicht die Aussage eines hohen Lotus@IBM Managers, dass der Classloader der attachten jars als solcher zu memory leaks führen.
3.1. Bei diesem Vorgang kann jetzt etwas schiefgehen, das habe ich schon verstanden. Einigen Foren-Posts zufolge kann ein stark belasteter Domino Server z.B. beim detachen in ein Timeout laufen. Da ich mein Problem auf einem Testserver, auf dem ausschließlich dieser eine Agent läuft, nachvollziehen kann, schließe ich sowas schonmal aus.
Hat nix mit der Belastung des Servers zu tun. Aus irgendwelchen Gründen cached der Classloader die bereits geladenen Klassen nicht und läd sie immer neu. Dieses Verhalten läßt sich reproduzieren.
Bleibt die Frage, WAS geht da schief? Eine Dateiressource aus einer NSF in's Dateisystem schreiben... daß das technisch geht, habe ich erst einmal vorausgesetzt.
Ich kenne den internen Prozess des Classloading über die attachten jars im Agenten nicht.
Nimm das jetzt nicht persönlich, aber ich bin nun mal bei der Frage der übereifrigen Schlußfolgerungen bei unvollständigen Informationen stärker sensibilisiert als der Durchschnitt:
Ohne den entsprechenden Source Code, der weder Dir noch mir zur Verfügung steht, befinden sich Spekulationen über Details des Prozesses aus einer wissenschafts-artigen Perspektive letztlich auf dem gleichen Niveau wie die Frage, ob diese Marienerscheinungen (
http://de.wikipedia.org/wiki/Marienerscheinung) in der Realität oder der Einbildung der Beteiligten stattgefunden hat.
4. Im Notes Log steht "... JVMDUMP006I Speicherauszugsereignis "systhrow", Detail "java/lang/OutOfMemoryError" wird verarbeitet", also habe ich erst einmal in dieser Richtung weitergemacht und versucht, etwas mit den Dumps anzufangen.
... und ich hab Dich darauf aufmerksam gemacht, dass Hashtable und java.policy Einträge in dem Kontext eines kaputten Classloaders völlig erwartbar sind...
Java Classloader speichern Klassen in Hashtable-Entries und sie laden auch die policy files.
5. Vielleicht kann ich die Aussagen der Analyse-Tools im IBM Support Assistant ja nicht richtig interpretieren. Da mir die IBM Experten bisher nicht helfen konnten, habe ich es trotzdem mal versucht, mich mit dem Thema zu beschäftigen. Wenn ich die Memory Dump Diagnostics über ein *.phd File laufen lasse, dann tauchen dort als "Verlustkandidaten" auch immer wieder "java/Security/..." Einträge auf.
... und daraus schließt Du, dass das Auslagern von jar Files auf Platte "unsicher" wär?. Ein wirklich interessanter Schluß.
An dieser Stelle habe ich mich gefragt, was genau passiert, wenn ein JAR aus einer NSF extrahiert wird. Weißt Du es? Wird die JAR-Datei tatsächlich in's Filesystem geschrieben? Wenn ja - in welches Verzeichnis? Was passiert dabei noch? Muß etwas beachtet werden, damit alles funktioniert? Wenn ja - was?
Es interessiert mich überhaupt nicht. Ich find auch das re-engineeren von closed source Prozessen, die ein hoher IBM Manager von Lotus@IBM als broken darstellt, als einen sehr fragwürdigen Zeitvertreib.
Jetzt die Spekulation (nochmal: bitte nicht gleich explodieren, ich laß' es mir gern erklären):
- wenn ein Prozeß auf eine Ressource nicht zugreifen kann, dann kann das unterschiedliche Ursachen haben: Variante1 - Ressource nicht da. Variante 2 - keine ausreichenden Rechte. Variante 3 - ein anderes technisches Problem.
- Variante 1 habe ich ausgeschlossen, da die JAR Files in der NSF sind und sich manuell auch detachen lassen.
- Für Variante 3 habe ich erst einmal keine weiteren Indizien.
- Bleibt Variante 2 - Rechteprobleme. Hm.
- was, wenn der AgentLoader ein Rechteproblem mit den JAR's hat? Im weitesten Sinne? Die aufrufende Methode, bei der etwas schiefgeht, könnte dann "explodeArchive" und "addAttachment" sein (wenn man dem Notes Log glauben darf), die URSACHE liegt vielleicht davor?
- Bsp. (Achtung: reines Gedankenexperiment!!!): die JAR's werden in /jvm/lib/temp geschrieben, auf dieses Verzeichnis hat der AgentLoader warum-auch-immer nicht die richtigen Rechte... Ergebnis: Fehler. Irgendetwas in der Art?
Ich stelle eine ganz andere Frage: Das Memory-Leak kommt dadurch zustande, dass der Classloader den Bytecode der entsprechenden Klassen immer neu läd, obwohl er sie bereits im Speicher hat. Das führt irgendwann zur Out of Memory Exception. Das hat nix mit dem Zugriff auf die Ressourcen zu tun. Der ist immer vorhanden.
Die Db ist komplett durchsigniert, d.h. die Domino Gestaltungselemente sind es. Aber Ressourcen, wie z.B. JAR-Files? Wie soll ich die aus Notes heraus signieren? Außerdem hat die Notes Signatur mit Java-Security wenig zu tun (glaube ich zu wissen) - es sei denn, IBM hat da was eigenes in die JVM eingebaut.
Kein IT-System ist völlig sicher. In Lotus hats über die letzten 10 Jahre z.T. heftige Security Leaks gegeben.
Ist signierter Code wirklich kriegs-entscheidend? Ich vermute etwa sehr stark, dass in der E-Banking meiner Bank nix signiert wird. Die sichern einfach den Produktionsserver entsprechend ab, dass dem niemand veränderten Code unterschiebt. Die beiden dominierenden Systeme im Enterprise Umfeld (JEE und .NET) kennen dieses Feature meines Wissens nicht. Damit halte ich es für eine ziemlich steile These, Signieren von Code als notwendige Bedingung für eine hinreichend sichere IT-Infrastruktur zu erklären.
JavaSpaces und JINI kannten signierten Code. Das konnte sich aber - ausser in Nischen - nie wirklich durchsetzen ... und dort auch nicht wegen dem Signier-Feature sondern aus anderen Gründen.
Zum Thema PMR und IBM: Wenn es ein bekanntes(!) Problem mit dem Agentloader gibt, sollen die IBM-Leute es einfach offiziell sagen und (1) einen Workaround anbieten und (2) einen Termin/eine Version benennen, wo der Prozeß (wieder) funktioniert. Was ist daran so schlimm?
Daran ist nix schlimm, es wäre sogar sehr schön. IBM agiert aber einfach nicht so. Die Anreizstrukturen der Entscheider bei IBM als börsennotierter, global agierender Konzern legen zunächst einmal die Vermutung nahe, dass solche arbeits-ethischen Fragen eine höchst untergeordnete oder überhaupt keine Rolle spielen. Hier ein paar interessante Beiträge, inklusive Diskussion.
http://www.cringely.com/tag/ibm/ 
Autor