lotus.domino.AgentLoader @ 0x7fff6ecd840von dem Tool, gibt es ein Problem mit dem ClassLoader, der völlig in Verantwortung von IBM liegt.
java.util.Hashtable$Entry[]
Dann ohne "PMR" formuliert: Wie soll IBM das Problem fixen, wenn niemand einen Bugreport erstellt?
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
Im Verlaufe der Konversation mit BigBlue hat man uns auch geraten, die im Projekt enthaltenen JAR's extern abzulegen im /jvm/lib/ext Verzeichnis und ja... das brachte was. Aber: wir wollen das nicht. Das Einbetten von JAR's in eine NotesDB ist eine von IBM angebotene Funktion und die soll bitteschönn auch richtig funktionieren. Hat ja auch alles prima geklappt in R7, warum nicht in R85?
/OT Ja, ich bin ein bischen stur. ::) /OT
Soooo.... jetzt noch ein paar Ergänzungen zum Thread selbst.Wo hast Du denn das her? Der java.security ist es völlig Wumpe, ob die Klassen von einem höheren oder darunterliegenden Classloader geladen werden. 95% aller Java Agenten laufen auf dem Server. Wer benötigt wirklich signierten Code auf Servern, die ohnehin anderweitig abgesichert werden? Ich hab ausser vor ca. 9 Jahren für Applets oder für Swing Anwendungen nie in meinem Leben ein java.policy File angerührt. Man kann das mit einem Häckchen im Agenten selber regeln.
- Neben den LND (Lotus Notes Diagnostic Tools) zur Analyse von NSD Files gibts auch noch ISA (IBM Support Assistant), eine Art Framework zur Fehleranalyse von IBM Produkten. Im ISA kann man ein paar nette Analyse-Module zum Thema Java Dump Analyse runterladen und nutzen.
- Bei uns war es so, daß neben java/lang/ClassLoader auch noch java/security/Policy Unmengen java/util/Hashtable$Entry, byte[] und ein paar java/util/HashMap$Entry gefressen haben
- was passiert, wenn man JAR's in's /jvm/lib/ext legt? Üblicherweise steht im \jvm\lib\security\java.policy File folgendes:Code// Standard extensions get all permissions by default grant codeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission; };
--> Jetzt noch 1 und 1 zusammenzählen:Leider zählst Du 1 und 1 auf Basis von Vorstellungen zusammen, die aus meiner Sicht mit der Realität nichts zu tun haben.
So hat geklappt. Ich musste den Server neu starten.
UND JA. Wenn ich so einen Magischen Realismus lese, werde ich sauer.
Hallo Th.
Lass dich von Axel (aka Pitiyankee) nicht verunsichern. Er liefert oft sehr wertvolle Inputes zu Problemen, aber ab und zu versteht man entweder nicht was er meint, bzw. benutzt er einen Thread einfach mal zu Dampf ablassen. Also einfach seine Postings mit Gelassenheit lesen, nicht persönlich nehmen und einen Nutzen aus seiner großen Erfahrung im Bereich verteilte Systeme Frameworks, Südamerika ;-) usw. ziehen.
Grüße
Ralf
- was passiert, wenn man JAR's in's /jvm/lib/ext legt? Üblicherweise steht im \jvm\lib\security\java.policy File folgendes:
Code:
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
Im ISA kann man ein paar nette Analyse-Module zum Thema Java Dump Analyse runterladen und nutzen.
- Bei uns war es so, daß neben java/lang/ClassLoader auch noch java/security/Policy Unmengen java/util/Hashtable$Entry, byte[] und ein paar java/util/HashMap$Entry gefressen haben
Pfff. Man muß mir ja nicht antworten. :)
Ich will keinen "Dampf ablassen". Ich will diskutieren.
Erklär mir bitte einmal diese Aussage. Ich verstehe sie nicht.Zitat- was passiert, wenn man JAR's in's /jvm/lib/ext legt? Üblicherweise steht im \jvm\lib\security\java.policy File folgendes:
Code:
// Standard extensions get all permissions by default
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
Das ist afaik schlicht und einfach nicht wahr. Das eine hat mit dem anderen nichts zu tun.
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.
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.
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):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.
- 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?
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.
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.
laut IBM-Support sind zwei "Speicherfresser" Mechanismen am Werk: das reine Laden der JAR's und ein zweiter, noch unbekannter Prozeß.Und in den vielen anderen Projekten seit vielen Jahren, an denen ich beteiligt war oder von denen ich gehört habe, wars dieser "unbekannte" Prozess, der dazu führt, daß man mit Anhängen von jars an den Agenten Speicherleaks hat und mit verlegen der Dateien ins lib/ext plötzlich nicht mehr.