Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

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

<< < (4/6) > >>

thkn777:

--- Zitat von: m3 am 08.03.12 - 09:00:49 ---Dann ohne "PMR" formuliert: Wie soll IBM das Problem fixen, wenn niemand einen Bugreport erstellt?

--- Ende Zitat ---

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:


--- Code: ---// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
--- Ende Code ---

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

flaite:

--- Zitat von: thkn777 am 24.04.12 - 11:19:21 ---
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

--- Ende Zitat ---

Kann ich überhaupt nicht nachvollziehen.
IT Systeme sollen die Geschäftsprozesse eines Unternehmens unterstützen.
Für dieses Ziel sollten die Anwendungen möglichst störungsfrei laufen.
Ende. Aus.
Mickey Maus.


--- Zitat von: thkn777 am 24.04.12 - 11:19:21 ---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:


--- Code: ---// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
--- Ende Code ---

--- Ende Zitat ---
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.
Java Classloader speichern Klassen in Hashtable-Entries und sie laden auch die policy files. Das ist also eine Folge des Classloader Memory Leaks.



--- Zitat von: thkn777 am 24.04.12 - 11:19:21 -----> Jetzt noch 1 und 1 zusammenzählen:

--- Ende Zitat ---
Leider zählst Du 1 und 1 auf Basis von Vorstellungen zusammen, die aus meiner Sicht mit der Realität nichts zu tun haben.
Die Beschäftigung der Grundlagen der JVM Laufzeitumgebung würd vermutlich mehr bringen als ein pseudo-intelektuelles Getüftel mit IBM Tools, deren output Du aus meiner Sicht nicht wirklich analysieren kannst.

UND JA. Wenn ich so einen Magischen Realismus lese, werde ich sauer.

pedsola:

--- Zitat von: Fragensteller am 06.03.12 - 11:22:34 ---So hat geklappt. Ich musste den Server neu starten.

--- Ende Zitat ---

ein bisschen spät und hat mit der letzten Diskussion nicht viel zu tun aber vielleicht hilfreich für den ein oder anderen.
Amgr restart reicht aus, um die JARs im ext-Verzeichnis neu einzulesen.

thkn777:

--- Zitat von: Pitiyankee am 24.04.12 - 14:24:48 ---UND JA. Wenn ich so einen Magischen Realismus lese, werde ich sauer.

--- Ende Zitat ---

Das möchte ich auf keinen Fall! Ich fasse daher meinen ersten Beitrag wie folgt zusammen und halte mich dabei streng an die Tatsachen:

Wir haben zu diesem Thema bei IBM mehrere PMR's eröffnet. Bisher haben wir unsere Probleme dadurch nicht nachvollziehbar erkären und lösen können.

Th.

Ralf_M_Petter:
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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete