Möglichkeit Timeout bei ProgrammCall

[BenderD]

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

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

[RobertPic]

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

Genau. Prinzipiell funktioniert die Wartezeit bei der Toolbox. Der Wartemechanismus ist aber nur serverseitig implementiert.

Das eigentliche Problem ist aber, dass der DataQueue.read keine Exception wirft, wenn die AS/400 weg ist (und die Javaprogramme auf Windows- bzw. Linux laufen). Der Job bleibt auf warten, auch wenn die AS/400 schon längst wieder da ist und neue Einträge warten.

Daher meine "Hurra ich lebe noch" Kontrolle für meine 24x7-Jobs (auf Linux und Windows).

Bei einem Blick in JTOPEN-Forum ist auch keine Hilfe für dieses Problem ist Aussicht gestellt worden. (http://www-912.ibm.com/j_dir/JTOpen....7?OpenDocument)

Bei Calls (über stored Procedures) bin ich bisher ohne Timeouts ausgekommen.

Robert P.

[BenderD]

Hallo,

dann wäre es doch eigentlich besser, einen eigenen Wrapper (extends ... DataQueue) zu schreiben und die read Methode zu überschreiben der genau dies kapselt.

mfg

Dieter Bender

PS: oder diesen Toolbox Schmonz durch eine (schmale) Schicht von stored Procedures zu ersetzen, oder vom Design her ganz darauf zu verzichten.

Genau. Prinzipiell funktioniert die Wartezeit bei der Toolbox. Der Wartemechanismus ist aber nur serverseitig implementiert.

Das eigentliche Problem ist aber, dass der DataQueue.read keine Exception wirft, wenn die AS/400 weg ist (und die Javaprogramme auf Windows- bzw. Linux laufen). Der Job bleibt auf warten, auch wenn die AS/400 schon längst wieder da ist und neue Einträge warten.

Daher meine "Hurra ich lebe noch" Kontrolle für meine 24x7-Jobs (auf Linux und Windows).

Bei einem Blick in JTOPEN-Forum ist auch keine Hilfe für dieses Problem ist Aussicht gestellt worden. (http://www-912.ibm.com/j_dir/JTOpen....7?OpenDocument)

Bei Calls (über stored Procedures) bin ich bisher ohne Timeouts ausgekommen.

Robert P.

[RobertPic]

Hallo

dann wäre es doch eigentlich besser, einen eigenen Wrapper (extends ... DataQueue) zu schreiben und die read Methode zu überschreiben der genau dies kapselt.

Das wäre sicher einen Tick schöner, allerdings kommt der DataQueue.read bei mir nur einmal in meinem (oft verwendeten) DataQueueListener vor.

PS: oder diesen Toolbox Schmonz durch eine (schmale) Schicht von stored Procedures zu ersetzen, oder vom Design her ganz darauf zu verzichten.

Derzeit habe ich nur 2 Arten von Kommunikation:
1. Javajob (auf AS/400, Linux, PC) wird per DataQueue getriggert. z.B. PDF-Wandlung, neue Daten für Spedition...

2. Wenn die Daten von "Außen" kommen, z.B. XML-Datei vom EDIFACT-Konverter werden die Arbeiten vom Javaprogramm erledigt/vorbereitet (z.B. XML-Datei in die Datenbank mappen) und anschließend eine stored Procedure aufgerufen, welche z.B. die EDFIACT-Bestellung verarbeitet.

Bei den nächsten Projekten müssen viele 5250-Clients (schnell) bedient werden. Ich werde daher eine Lösung mit Sockets anstreben.

Für den Client-(ILE)-Teil gibt es Freeware von IBM, welche angeblich ganz brauchbar ist (aus RPG, Cobol... ähnlich einfach wie DataQueues).
Seit der Registrierung ist jetzt eine Woche vergangen....ich berichte dann über die "Tauglichkeit".

[BenderD]

Hallo Robert,

ich hatte mit dem extend auf die DataQueue mehr die Zentralisierung in einem Objekt im Blick; im Grunde will eine Applikation Daten und sonst nix, es sei denn es geht was schief, dann wird eine exception erwartet; dass das ganze irgendwo durch eine DataQ durchgeknebelt wird, ist der Applikation egal.
Mit den Sockets bin ich mir nicht sicher, ob du da einen guten Tausch machst, es sei denn du schreibst den zentrale Dispatcher, der die Anfragen annimmt und verteilt in C. Wenn du für jeden 5250 Client von vornherein einen eigenen Server startest, dann gibt das einigen Overhead und Probleme, wenn so'n Ding wegschläft oder abschmiert, bei einer 1 zu n Lösung geht nix ohne Multithreading und das kann weder RPG noch Cobol auf der AS/400.
Ich würde da als Schmalspur zu einem DataQ basierten Dispatcher tendieren und den in Java schreiben. Wenn man es schick machen will, dann könnte man das ganze auch als WebService erscheinen lassen; dann kann man einen fertigen Server verwenden und braucht dann für die Clients eine schmale Schicht, die die Daten aufbereitet; dafür würde dann ein Schmalspur Parser als Adapter reichen.

mfg

Dieter Bender

Hallo

Das wäre sicher einen Tick schöner, allerdings kommt der DataQueue.read bei mir nur einmal in meinem (oft verwendeten) DataQueueListener vor.


Derzeit habe ich nur 2 Arten von Kommunikation:
1. Javajob (auf AS/400, Linux, PC) wird per DataQueue getriggert. z.B. PDF-Wandlung, neue Daten für Spedition...

2. Wenn die Daten von "Außen" kommen, z.B. XML-Datei vom EDIFACT-Konverter werden die Arbeiten vom Javaprogramm erledigt/vorbereitet (z.B. XML-Datei in die Datenbank mappen) und anschließend eine stored Procedure aufgerufen, welche z.B. die EDFIACT-Bestellung verarbeitet.

Bei den nächsten Projekten müssen viele 5250-Clients (schnell) bedient werden. Ich werde daher eine Lösung mit Sockets anstreben.

Für den Client-(ILE)-Teil gibt es Freeware von IBM, welche angeblich ganz brauchbar ist (aus RPG, Cobol... ähnlich einfach wie DataQueues).
Seit der Registrierung ist jetzt eine Woche vergangen....ich berichte dann über die "Tauglichkeit".

[RobertPic]

Mit den Sockets bin ich mir nicht sicher, ob du da einen guten Tausch machst, es sei denn du schreibst den zentrale Dispatcher, der die Anfragen annimmt und verteilt in C.

1. Die bestehenden Anwendungen bleiben. Es geht nur um "interaktive" Abfragen: fremde Datenbanken, WebService....

2. Keine Sorge, der (Socket-) Serverteil/Dispatcher ist in Java geschrieben. Ich habe schon so ein Teil laufen, um unseren externen WebServer mit Daten zu füttern.

...... wenn so'n Ding wegschläft oder abschmiert, bei einer 1 zu n Lösung geht nix ohne Multithreading und das kann weder RPG noch Cobol auf der AS/400.

Ich will ja nur den Client-Teil mit 3GL "verseuchen". Für den Client ist es ja eine 1:1 Verbindung. Die große Frage für mich ist noch, was die IBM-Freeware taugt (denke doch in C geschrieben). Ich werde berichten.

Ich würde da als Schmalspur zu einem DataQ basierten Dispatcher tendieren und den in Java schreiben.

Das entspricht weitgehend meinem Plan B, PLAN C wäre die Clientseite mit selbst mit C zu coden.

Als Vorteil der Sockets sehe ich, dass ich mich nicht um den Rückantwortkanal kümmern muss bzw. irgendwelche Daten "auseinanderklauben" muss. Ob die Vorteile überwiegen, wird sich noch zeigen....

Robert P.