Dann ohne "PMR" formuliert: Wie soll IBM das Problem fixen, wenn niemand einen Bugreport erstellt?
Guten Morgen,
die hier angesprochenen Probleme kommen mir doch recht bekannt vor und während ich meist stummer Mitleser bin und mich über die vielen Anregungen hier im Forum freue, möchte ich doch kurz auf Deine obige Antwort eingehen.
Eine kleine Geschichte:
Es war einmal ein Domino Cluster R7.03, auf dem ein Java Agent in mehreren unterschiedlichen DB's jahrelang seinen Dienst tat. Völlig unauffällig, stabil und betreuungsfreundlich.
Dann kam das Serverupdate (852FP1) und die JVM Dumps. Nach etwas selber Rumprobieren dann der erste PMR (40456), der nach längerem Hin- und her zu SPR # MCOA8C7CNX führte und uns einen Hotfix brachte, der das Problem (scheinbar) löste. Mit R853 sei das Problem dann sowieso endgültig aus der Welt... so ging die Mär.
R852FP3 kam und die JVM Dumps kehrten wieder. Der nächste PMR (40822) brachte keine Hotfixes, sondern ein Vertrösten auf R853. Dort sei alles gut... wirklich.
R853 kam und die JVM Dumps waren schlimmer denn je. Der aktuelle PMR (41089) ist seit 222 Tagen offen und ungelöst.
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.
- 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:
// 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: soso... wenn ich die JAR's also raus aus der NSF nehme und die Security abschalte, dann läuft plötzlich alles, ja? Das Thema habe ich beim freundlichen Herrn aus Irland auch mal angesprochen, Ergebnis: ich war wieder mal viel zu mißtrauisch und auf der völlig falschen Fährte, das hat alles gar nichts zu bedeuten.
Wie geht's weiter?
- recycle etc. haben wir alles schon durch
- im Moment stürzen wir uns auf Driver de-registration, was vielleicht auch ganz gut hier (
http://atnotes.de/index.php/topic,53506.0.html) reinpaßt, allerdings hat der Thread schon ein paar Tage auf dem Buckel. Wenn's Euch interessiert, kann ich dazu ja nochmal was schreiben.
Meine persönliche Spielwiese im Moment:
Ich bin darüber gestolpert, daß sich der Notes 8.53 Entwickler Client projektbezogen und teilweise scriptbezogen die Java Compiler Settings merkt. (
Jaja... jetzt, wo ich weiß, wonach ich suche, findet auch Frau g**gle was dazu *hust* ) Auch wenn das für alle Beteiligten hier ein alter Hut ist... mir war nicht klar, daß ich nicht einfach den Agent im 8ter Developer Client neu übersetzen kann und er dann auch mit JDK 1.6 Konformität läuft. Ich habe mir also gerade in den Kopf gesetzt, das mal ein wenig zu testen, ggf. kommt ja die R85 JVM einfach nicht so richtig mit dem alten JDK 1.3/4 Zeugs klar?
Tja, soviel dazu... ich stapf dann mal zurück an die Arbeit und kann wenn Ihr mögt, gerne mal ein Update zum aktuell offenen PMR geben
Th.
Thema: JVMDUMP006I Speicherauszugsereignis "systhrow" wird verarbeitet; Detail "java/la (Gelesen 22719 mal)