JVMDUMP006I Speicherauszugsereignis "systhrow" wird verarbeitet; Detail "java/la

[thkn777]

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

Gruß zurück
und danke für die Aufmunterung. Ich bin ganz ruhig und bringe jede Menge Geduld und freundliche Gesichter hierher mit in's Forum. Ich hab' um die eigentliche Kerninformation (ja, IBM hat zu dem Thema PMR's) einfach noch was drumrumgeschrieben, um quasi mal auf den Busch zu klopfen.

Eine mögliche Lösung für mein Problem ist ja vielleicht noch RITA (siehe http://www.rfc-editor.org/rfc/rfc2321.txt )...hm.  

Ich wünsche allen einen entspannten Restarbeitstag und danach einen hoffentlich erholsamen Feierabend.

Th.

[flaite]

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.

- 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.

Und deine ISA-Analyse

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

zeigt eigentlich nix anders, als dass eben der CLASSLOADER von attachten Code in den Agenten ein Memory Leak hat. Und zwar übrigens seit mindestens 7 und vermutlich seit 12 Jahren. Warum sollten sie das in überschaubarer Zeit jetzt fixen, wenn Du einen weiteren PMR aufmachst?

PMRs besitzen reinen Vorschlag-Charakter. IBM hat sich nirgendwo commited, wie sie auf einen PMR reagieren.
Und ja. Genau da ist ein emotionaler Punkt in mir. Ich erleb auf Java-Plattformen seit Jahren immer wieder, dass Entscheider frustrierende Fehl-Investitionen fällen, weil sie nämlich der Marke IBM zu blind vertrauen. Damit sag ich nicht, dass jedes IBM Produkt fehl am Platz ist. Oft werden sie aber an einen Platz gestellt, an dem sie nicht hingehören. Und mit den PMRs ist das ähnlich. Der Marke wird halt vertraut. Soweit zumindest meine Perzeption.
Du kritisierst zwar IBM, besitzt aber einen für mich ganz ernsthaft schockierend festen Glauben in dieses PMR Ding an sich.

Das war oben echt ein wenig schroff, deshalb zorry. Manchmal agier ich hier aus Gewohnheit schräg, was irgendwie auch nicht ganz töff ist.

ICH RATE DRINGEND, EINFACH MAL DIE JARs TESTWEISE INS LIB-EXT ZU LEGEN. Du brauchst auch keine policy-files zu editieren. 

[thkn777]

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.

- 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.

Moin moin,
also erstmal vorneweg: ich will nicht wieder "an-ecken", ok? Also bitte nicht gleich explodieren, wenn ich jetzt frage: "warum nicht?". Hilf mir doch hier bitte mal über den Berg, vielleicht habe ich mich ja völlig in die falsche Ecke verirrt. Eine einfache und nachvollziehbare Erklärung konnte mir bisher niemand geben    .

Der Reihe nach:

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.

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?

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"?

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.

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.

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.

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.

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?

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?

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.

Ich habe bisher keine schlüssige Erklärung für meine Fragen gefunden, daher - da hast Du völlig Recht - ist das reine Spekulation. Ich hoffe, daß ich zumindest erklären konnte, wo mein Verständnisproblem liegt und wie ich auf die Security-Schiene gekommen bin. Ist vielleicht ein Holzweg - ok. Mir wäre es sehr lieb, wenn ich das Problem abhaken könnte, möchte es vorher aber bitte verstehen.

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? Ich habe schon mit vielen IT-Firmen zu tun gehabt - immer gab es irgendwelche Probleme. IBM ist da keine Ausnahme und ich vertraue auf IBM-Lösungen auch erst dann, wenn ich sehe, daß alles funktioniert - und nicht auf das bloße Wort hin. Gerade bei PMR's habe ich den Eindruck, das meiste alleine machen zu müssen und die IBM-Supporter mit Ideen und Lösungsvorschlägen unterstützen zu müssen... vielleicht kommt daher auch mein Antrieb in diesem Fall, selbst noch etwas nachzuforschen.

So... ich hoffe, wir können aus meiner holprigen Vorlage jetzt noch was Sinnvolles machen 

[flaite]

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/
 

[thkn777]

Ohje, jetzt habe ich ein schlechtes Gewissen 

Hier der abschließenden Stand zu diesem Problem von meiner Seite:
- laut IBM-Support sind zwei "Speicherfresser" Mechanismen am Werk: das reine Laden der JAR's und ein zweiter, noch unbekannter Prozeß. So, wie ich den Support verstanden habe, ist es der zweite Prozeß, der das eigentliche Problem darstellt, die Speicherbelastung durch die JAR's ist nur weitaus größer und erscheint deshalb als Nr. 1 Problem in Analysen.
- Ich habe eine Referenz-DB gebaut, in der die Agenten und JAR's etc. enthalten sind, diese ist für weitere Tests laut Support an's QE (Quality Engineering) gegangen
- "offizieller" Workaround (sprich: mit dem Support abgestimmt): JAR's in's jvm/lib/ext schieben  --> ist jetzt umgesetzt und läuft stabil
- für den Fall wurde SPR # BHUY8VML6R generiert und APAR # LO70204. Wenn man im Web danach sucht, kommt man zu http://www-01.ibm.com/support/docview.wss?uid=swg1LO70204 und das läßt mich jetzt nicht darauf hoffen, daß es eine schnelle Lösung gibt.
- von meiner Seite ist damit das Ende der Fahnenstange erreicht, mir gefällt zwar das Ergebnis nicht, aber der Fall ist hinreichend geklärt, die DB's sind arbeitsfähig --> Schluß.

Nochmal ENTSCHULDIGUNG, daß ich erst jetzt den Thread aktualisiere. Erst ist was dazwischengekommen und dann hab' ich es schlichtweg vergessen.

Danke an alle für die Hilfe,
Th.


P.S. @Pitiyankee
Danke für Deinen letzten ausführlichen Beitrag. Die java.policy Datei und ggf. Agenteneinstellungen sehe ich mir nochmal an - es stört mich schon ziemlich, daß jedes Notes Update die java.policy überschreibt... von daher wäre eine DB-spezifische Einstellung deutlich besser und betriebssicherer.

[flaite]

Vielen Dank für die Rückmeldung.  
Und ernsthaft Entschuldigung für meine ausraster weiter oben. Geht mir oft als Externer so, dass ich zwar ein gutes Einkommen erziele, aber oft mit Vorschlägen aufgrund meiner schwachen Stellung in der Organisation politisch nicht durchkomme.
Ich WUSSTE, dass der Fehler verschwindet, wenn Du die jars ins lib/ext verschiebst. An Dir konnte ich dann meinen Emotionen freien Lauf lassen. Das geht nicht. Aggression hat fast immer seinen Ursprung in Gefühlen wie Verzweifelung und Angst. Bei mir zumindest. Muss das kontrollieren. Auch online.  
 

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.
"Unbekannter Prozess" halte ich für einen Euphemismus für "Wir wissen, dass Classloading von attachten jars an Agenten fundamental kaputt ist, können das - aus welchen Gründen auch immer - nicht fixen, wollen das aber auch nicht öffentlich zugeben".   

Ich kenne einen Fall, wo an der java-policy Datei rumschrauben mußten und das ganze war praktisch schon ein verbogener Domino-Server. Wegen irgendwas mit einer eigenen Verschlüsselung der Kommunikation mit symmetrischen Schlüsseln. Ich hab hier kein Notes auf dem Rechner, aber es gibt eine Einstellung auf der ersten Seite der Einstellung von Java Agenten.  

Geh jetzt 2 Runden um den See joggen. Mal schauen, ob ich das heute schaffe...