Hallo,

ich spüre da so ein leichtes Kräuseln meiner Nackenhaare, wenn ich das richtig verstanden habe, dann habe ich einen Java Client, der einen AS400 Serverdienst aufruft (sei es nun ein call via AS400 Objekt, oder ein JDBC Call), der seinerseits irgendwie hängen bleibt, oder nicht in die Pötte kommt. Solange dieses AS400 Programm vor sich hin dümpelt, solange wird kein Garbage Collector es wegräumen, vermutlich funzt dann nicht mal finalize und dann müllt sich das ganze mit womöglich ewig hängenden Leichen zu. Den Ansatz das auf dem Client zu monitoren und von dort den Thread aufzugeben, das würde ich bleiben lassen.
Auf dem Server einen Monitor einzubauen, scheitert vermutlich daran, dass es sich um einen RPG Schinken handelt, deer keinen Monitor Thread hat und haben kann.
Ich würde hier ganz entschieden für ein Redesign und neu schreiben der AS400 Seite plädieren (wahrscheinlich liest der eh nur aus der Datenbank). Sollte das absolut nicht gehen, weil keiner mehr weiß, was dieses Teil treibt, oder selbiges solch wertvolle Gedanken enthält, auf die man kein zweites Mal kommt, dann wäre das eine der ganz abgezählten Ausnahmen in denen ich auf die synchrone Variante setzen würde:
- aus Java per JNI aufrufen
- Monitor Thread in Java
- bei timeout Exception Aufruf abbrechen
- das RPG Teil keinesfalls mit Thread serializable wandeln
- nach Abbruch das Java Objekt dem Garbage Kollektor überlassen

Bei Stresstests dieser Art würde ich immer das AS400 Objekt meiden und selbiges nur über den jt400 Treiber versuchen, auch vom native Treiber würde ich hier wg. Buggy Syndromen die Finger lassen.

@Baldur: die Thread Safe Sache hat mit der Möglichkeit einen Thread zu starten nix zu tun. Der Job (in dem das Java Teil läuft) muss Multithreading erlauben, das Subsystem muss über entsprechende Anzahl von activity levels verfügen, das Subsystem muss einen eventuell zusätzlichen Qshell Job erlauben und das wars. Thread *serializable bewirkt lediglich, dass man nicht zweimal gleichzeitig in dasselbe Modul reinkommt, die Aufrufe werden geblockt, bis der, der gerade dran ist, zurück kommt. Das ist sowohl unzureichend (export von Variablen), wie gefährlich (Verklemmungen durch Deadlocks).

@Robert: wenn ich das richtig verstehe, brauchst du den Monitro Mechanismus nur, weil die DTAQ Implementierung der Toolbox nicht das tut, was sie soll?! die soll doch gerade nach waitSec aufhören, wie sie das mit AS400 API auch tut.

mfg

Dieter Bender

PS: die rein AS400 seitige Lösung über Zwischenschaltung einer DTAQ wäre vielleicht sogar noch das beste:
- Aufuf eines AS400 Programms per JDBC
- selbiges stellt eine Anforderung in eine DTAQ und wartet n sek auf Antwort
- wenn der wait zuschlägt Rückgabe an Java Programm "wwn" (war wohl nix) und Abbruch des RPG Schinkens



Zitat Zitat von Fuerchau
Im Falle eines nötigen Cancels sollte man die Verbindung komplett freigeben und vom Garbagecollector auflösen lassen.
Ein Reconnect könnte auch Resourcenprobleme bereiten, eine nagelneue Verbindung bekommt sicherlich auch einen neuen Job.
Achtung Ausnahme: ConnectionPooling !!!