Java Agent crasht Server wegen Semaphoren- Lock...

[Tode]

... So viel kann man aus dem NSD schließen.

Dummerweise haben wir (Admin vor Ort und ich) nur eine vage Vermutung:
- Wo der Java- Agent ist
- Wie der Agent aufgerufen wird

Ich weiß nur: Eigentlich laufen auf dem Server 4 Instanzen des aMGR. Als der Server gecrashed ist, waren 12 amgr Instanzen aktiv...

Das heißt: Die Agenten werden irgendwie "außerhalb des amgr" getriggert (z.B. RunOnServer, über einen http- request, o.ä.)

Jetzt die Preisfrage: wie finde ich am schnellsten raus, welcher Agent / welche Agenten das sind.
Eine Analyse aller Agenten mit AgentEZ hat keine möglichen Kandidaten enthüllt, und die Agenten, die wir verdächtigen, laufen eigentlich auf einem ganz anderen Server...

Hier die beiden Agenten aus dem NSD, die den Semaphoren- Lock und am Ende den Crash verursacht haben:

############################################################
### thread 14/16: [   nAMgr:  1180:  0474]
### FP=0xd482ef68, PC=0x773abb7a, SP=0xd482ef68
### stkbase=0xd4830000, total stksize=262144, used stksize=4248
############################################################
 [ 1] 0x773abb7a ntdll.ZwWaitForSingleObject+10 (1e228bc,7FEEF5F90BC,1257F7E002F0DCC,f40019c)
 [ 2] 0x7FEFD1110AC KERNELBASE.WaitForSingleObjectEx+156 (493,0,0,d4c)
@[ 3] 0x7FEF738BE72 nnotes.WaitOnNativeSemaphore+802 (0,0,7FF00000000,0)
@[ 4] 0x7FEF738CAFF nnotes.OSLockSemInt+287 (f40019c,474,7FFFF6E7500,4bb6e8)
@[ 5] 0x7FEF738DA0D nnotes.OSLockWriteSem+77 (2,f400198,d482f540,7FEEF4CBD8E)
@[ 6] 0x7FEEF46E1D1 nlsxbe.SRefLock::SRLockForDestruction+129 (0,d482f1d0,6fc480,53bc00)
@[ 7] 0x7FEEF4C9DC0 nlsxbe.LockSessForDestruction::LockSessForDestruction+32 (f402018,0,d482f540,7FFFF39AB74)
@[ 8] 0x7FEEF4CD618 nlsxbe.Java_lotus_domino_NotesThread_NnotesTermThread+456 (7d69b800,73bfd9d0,7d69b800,7FFC0CD65F0)

############################################################
### thread 15/16: [   nAMgr:  1180:  127c]
### FP=0xce69aa48, PC=0x773abb7a, SP=0xce69aa48
### stkbase=0xce6a0000, total stksize=262144, used stksize=21944
############################################################
 [ 1] 0x773abb7a ntdll.ZwWaitForSingleObject+10 (0,0,0,7FEF738B6F5)
 [ 2] 0x7FEFD1110AC KERNELBASE.WaitForSingleObjectEx+156 (535,0,0,1198)
@[ 3] 0x7FEF738BBF9 nnotes.WaitOnNativeSemaphore+169 (0,43700001,0,0)
@[ 4] 0x7FEF738CED3 nnotes.OSLockWriteFRWSemInt+435 (b780535,ce69b730,ce69b590,4e9700e0)
@[ 5] 0x7FEF738D98E nnotes.OSWaitFairEvent+30 (3273bd4,0,7FEF921DAE8,0)
@[ 6] 0x7FEF7EE241F nnotes.newLkLock+10671 (ce69ba10,ce69b688,4022,ffffffff)
@[ 7] 0x7FEF7EDB9F0 nnotes.LkLock+1888 (ce69ba10,ce69b688,4022,ffffffff)
@[ 8] 0x7FEF7F9A21C nnotes.LockDbReadSemCtxTimedInt+2700 (0,ffffffff,7FEF8C00418,0)
@[ 9] 0x7FEF7FBBF9A nnotes.NSFDbOpenExtended6+31322 (ce69ef70,7FE10000000,0,7FE00000000)
@[10] 0x7FEF7FBF93B nnotes.NSFDbOpenExtended3+155 (ce69ef7a,ce69f000,33,7FEF926C250)
@[11] 0x7FEF7FC03EB nnotes.NSFDbOpenExtended2+107 (ce69f000,0,ce69ef7a,33)
@[12] 0x7FEEF42BE39 nlsxbe.ANDatabase::ANDOpen+1113 (7d6afd00,1,0,7FEEF4D181E)
@[13] 0x7FEEF436A7E nlsxbe.Java_lotus_domino_local_Database_Nopen+270 (7d6afd00,d0bfca28,b8f,7FFC1B387B0)

Und hierher weiß ich das:

SEMDEBUG_SERVER1_2016_03_16@21_43_54.TXT
ti="000D1244-C1257F7E" sq="00095797" THREAD [1180:01B1-0474] WAITING FOR WRITE LOCK ON RWSEM 0x91BD  (@0F40019C) (R=0,W=1,WRITER=1180:127C,OWNER=1180:127C) FOR 30000 ms

[hallo.dirk]

hast Du mal weiter unten im NSD geschaut, welche Datenbanken von diesem Thread im Zugriff waren?
1180:  0474

Vielleicht hilft das schon dem Überltäter auf die schliche zu kommen....

Ich kann das schlecht abschätzen, aber könnte dir evtl der DEBUG_LS_DUMP=1 helfen?
http://www-01.ibm.com/support/docview.wss?uid=swg21499034

[Tode]

Die Datenbank habe ich identifizieren können, das war eine User- Maildatenbank. Das ist jetzt aber der zweite Crash dieser Art (der letzte war Anfang Februar), und dort war es eine andere User- Datenbank.

DEBUG_LS_DUMP ist eine gute Idee... nur fürchte ich, dass es nix bringt (ich glaube nicht, dass wir es hier mit Java zu tun haben, das aus LotusScript- Code aus aufgerufen wird)

[jBubbleBoy]

Ich kann etwas Brainstorming beitragen:

Wenn man sich dieses Problem durchliest könnt man denken das ein Java-Mail-Agent den Serverabsturz verursacht. Darauf hin habe das Notes Mail-Template (8.5 und 9) nach Java-Code durchsucht und nichts gefunden, kein Java-Agent, keine Java-Bibliothek, kein Webservice noch nicht einmal Java-Applet Ressourcen gibt es.

Java vs. Mail-DB, mein erster Gedanke war ein LS-Mail-Agent ruft einen entfernten Java-Agenten auf, das ist aber sehr unwahrscheinlich.
Mein 2. Gedanke, ein Java-Agent greift auf die Mail-DB zu, dem widerspricht aber das NSD-Log, welches ja die Mail-DB in den Fokus stellt. Aber was passiert wenn ein runOnServer ausgeführt wird oder noch besser es läuft der DIIOP Task auf dem Domino-Server und der Zugriff/Aufruf erfolgt über Corba, das erzeugt auf jeden Fall einen Java-Thread und der Ursprung liegt ganz wo anders, wie z.B. bei euren Hauptverdächtigen. Frage: Greifen diese verdächtigen Java-Agenten auf die Mail-DBs der User zu? Habt ihr einmal die Absturzzeiten mit den Agenten-Startzeiten geprüft? Und das auch auf dem Server mit den verdächtigen Java-Agenten?

vielleicht gibt es ja einen prassenden Denkanstoß ...